Handling Dependencies

[everythingfunctional]

My basic outline of how to do this is the following recursive algorithm:

1. for each listed dependency, download/check it out
2. Go into the dependency's fpm.toml file and for each of it's dependencies
   a. if it's already been downloaded, check that it's version is compatible, otherwise recursively repeat this process
3. Collect each of the dependencies dependencies,
4. Return the tree of dependencies
5. Build each of the dependencies, recursively building each of it's dependencies first

[everythingfunctional]

I should be able to implement this soon. I'll use a similar toml specification style as Rust's cargo. I got sidetracked implementing the ability to parse that properly for the toml parser we're using.

Which brings up a question. Do we specify the specific git version of that library as one of our dependencies, or do we include the functions I implemented directly in our source? For either, at some point we'll be able to remove it and go back to using the library as normal.

[LKedward]

Thanks @everythingfunctional, this will be great to get working! I have a few questions:

• At this stage are dependencies simply specified directly as git repository urls (Decentralized package management #33 decentralized package management)?
• Are you using git tags to track specific versions in git repositories?
• How are dependency versions specified in fpm.toml? (cargo supports several version operators)
• Are you adopting some form of semantic versioning rules to resolve version compatibility?
  • Also: surely you can only resolve compatible dependency versions after the entire dependency tree has been constructed?

[everythingfunctional]

For now, we'll just support git repository urls, since we don't have a centralized repo yet.

Just like cargo does, we'll support tags, commits, or branches being specified for a git dependency.

I'm planning to implement version specifications exactly like cargo does. That's a bit longer term goal though.

Yes, we'll adopt semantic versioning rules. Long term, it may even be possible to enforce those rules in a centralized repository.

In the short term, we won't "resolve" dependency versions. It will just check if the version already downloaded is compatible with the package's requirements. If not we'll just throw an error. You can then "resolve" the conflict by specifying a version that works for all the dependencies in your package. I don't know of any package manager that has really and truly solved the version compatibility search problem. Many have just reasonable approximations or workarounds.

[LKedward]

Closing as implemented in both versions of fpm.