How about --list for update subcommand?

[urbanjost]

I think it would be useful if the --list switch was added to the subcommand update and it showed the data including the commit of the git-based dependencies. If they were in the format of fpm.toml statements you could easily read them back into your package manifest file (ie. fpm.toml); helping you make sure it is reproduced properly in the future if the dependencies change. All the info seems to already be written into the build/cache.toml file so it looks like a very simple change. And at least currently I find I often wipe out the entire build/ directory or start a copy on another machine or directory, etc. ... -- so I often have multiple cache files or none at all. The --verbose switch almost does that; but is not showing the commit values.

I often start out with a dependency by just using the latest version and do not always remember to add a commit number (I do not really trust version numbers).

[awvwgk]

You can inspect the cache file in build/cache.toml if you are interested in the dependencies. This is not a long-term solution, but neither is the pinning of commits in the package manifest. We should aim for a dedicated lock file containing the commit information instead.

Listing dependencies can be done nevertheless, but it is more difficult for the update command to just list things, because it implies a dryrun which becomes impossible once it has to resolve and fetch a dependency to display accurate information.

fpm update --fetch-only --verbose is the closest to a dry-run/list functionality I could come up with.

[urbanjost]

Thanks for taking a look. It seemed simpler than that. But after an initial build or a fpm update --fetch-only --verbose that is very close except I do not see the commit values even though they appear in the cache file. So that would be close enough for me if the current version were displayed with that, --verbose flag or if --list just checked for the cache value and then replaced it with any specific value (now) in the manifest and warned that it could not display the list until an update or build(implicitly or explicity) had been executed if the manifest did not specify one (marking them as "current but latest on next pull" if not explicity labeled in the manifest); or it could just show what it found combing cache and manifest. Does start to sound complicated. Well, that's why I put this under the "ideas" category.
Thanks for the explanation and consideration!