Implement Dependency Management RFC 0005: New jam update-dependencies

[sophiewigmore]

Per Dependency Management RFC Phase 2, part of the new dependency update workflow there is an "assembly" step in which new dependency versions and metadata get added to the buildpack.toml.

This issue is to create a new jam command, which will eventually replace the existent jam update-dependencies command to update the buildpack.toml. The command will be extremely similar in that it will update the buildpack.toml, but it will no longer query the dep-server for metadata, and will instead receive a metadata.json.
A key difference is that it will expect that the metadata provided has already been checked against existent buildpack.toml versions and the version constraints. This means, the main job of the command is to take all of the new versions to be added, and appropriately sub them into the buildpack.toml to satisfy constraints (like number of patches for a version line).

Check out the RFC for details about what the command should do, and how it should fit into the future dependency update workflows.

Note that the new command cannot immediately replace jam update-dependencies because the old command will be needed for a period of time until migration to the new dependency management strategy is complete. The new command will need to be given a different name for the time being in order to avoid breakages in our current process.

Acceptance Criteria

I package up the version of jam on the related PR and:

• The jam update-dependencies --buildpack-file <path to buildpack.toml> command still works the same way as it does now, it will use the dep-server to update the buildpack.toml.

• The jam update-dependencies command can also take in a metadata-file argument, which must be the path to a JSON file containing metadata as outlined in the RFC.

  • The metadata may also now contain duplicate versions, which differ by the set of stacks. In this case the jam update-dependencies command adds both entries to the buildpack.toml. See this metadata file as an example, which can be used alongside this example buildpack.toml file.

[fg-j]

Maybe it's possible for jam update-dependencies to behave two different ways depending on if it receives a --buildpack-file or a --buildpack-file and --metadata-file.

jam update-dependencies --buildpack-file buildpack.toml works in the legacy way, but
jam update-dependencies --buildpack-file buildpack.toml --metadata-file metadata.json activates another code path that doesn't use the dep-server.

[robdimsdale]

I love that suggestion @fg-j ! I prefer that suggestion over making a new command and eventually retiring the existing one.

[sophiewigmore]

Agree!