I find I often want to change the dependencies in the fpm(1) manifest file fpm.toml
.
If I am modifying a package I want other packages that use it to try the new test version, probably from a local directory linked as a subdirectory in the packages that use it. The production version might use a package from the registry. If I am offline I might be pulling the package from an intranet site … .
Using git branches with alternate fpm.toml files; setup and teardown scripts and scripts and preprocessors all work but are not built in the base fpm(1) package and so present portability problems.
Is constantly needing dependencies resolved from different sources a rare condition or common? Would something simple like allowing fpm(1) to have duplicates for dependencies that are searched from top to bottom satisfy the most common situations? Would a new switch like --offline or --dependency NAME(S) work where a new keyword could be added to dependencies that would need matched? That is, --dependency registry,http,path,development,… would mean to look for dependencies with those keywords in that order first before using a default?
l
I am trying to determine if the problem is common enough to deserve a feature; if something simple is sufficient or if true conditional processing of the manifest file is required (which is not first-nature for TOML files), …
If my company ever adopts fpm for internal use, they will set up mirrors of all the fpm public sources on an internal site, and it will only be populated with packages that have been approved by security. So it will be mandatory for us to resolve them from a non-default source.
I work in several environments. In one similar to what you describe there are several approaches that already work.
One is to have a local mirror of the registry for registered packages and access other packages installed on the local intranet much like everything was on the www.
Assuming you have a file server visible to all your build environments the simplest seems to be to make a directory and place all the external packages there and then put a soft-link in your packages to that directory and use the path= form of the dependencies.
Some are arguing that the packages should just be built and installed and used like any other compiler library as an external library to reduce redundant compilation and allow for custom options to be used to build each library which is not fully supported in fpm using the other methods.
Everyone was content with building everything, which has some advantages when debugging. But as the packages grow having everything pre-built becomes more attractive.
But those are solutions for stable environments where you do not want to toggle.from one source to anoher. In those scenarios I think the most common change would be to want to test with a new version which is possible to do by changing links and github branches and so on but that I think would still be improved by having some built-in fpm feature.
t