This interface still doesn't make sense to me though - if we are listing dependencies as an argument to bundle/install, we could just check for their existence manually.

The "old" style of dependencies, where we reference more detail descriptions of where the dependencies come from should be able to work in parallel to the existing dependency mechanism, not replace it. The current dependency mechanism is mainly meant to prevent breakage of installed packages, and maintain some internal consistency. The old style of dependency management lives along side as :jpm-dependencies.

Would it be possible for your package manager to generate the :dependencies and pass that to info.jdn somehow, in the same way that project-janet-shim does?

I believe that the current implementation is itself broken insofar as a user would expect that :dependencies can take values that are the same as those taken by :dependencies in project.janet. To the extent that this behaviour is being relied upon, it is the behaviour that is broken and that should be fixed.

Perhaps, but I don't think that the above changes are the solution.

This interface still doesn't make sense to me though - if we are listing dependencies as an argument to bundle/install, we could just check for their existence manually.

The existence check that bundle/install performs at the moment is a check that the value in the :dependencies tuple/array matches a directory in <syspath>/bundle. If we want Janet to support :dependencies having more complex ‘coordinates’ that refer to remote locations, you cannot do it this way unless bundle/install can resolve a coordinate to its bundle name. That means bundle/install needs to be able to fetch files from the remote location so that it can look at the bundle’s info.jdn or project.janet file to determine its bundle name. That then requires bundle/install to be able to use some combination of curl, git and tar. I had thought this was unacceptable as the bundle functions are only meant to know what is on the local file system. Am I wrong on this?

Would it be possible for your package manager to generate the :dependencies and pass that to info.jdn somehow, in the same way that project-janet-shim does?

Yes, it is but this seems to me an extremely unsatisfactory solution. It would mean that my tool would create a ‘magic’ value in info.jdn (mapped to :dependencies) that the user must be aware that they should not edit by hand (even though they wrote info.jdn) lest they cause it to get out of sync with the value mapped to, say, :ok-to-edit-dependencies that they are able to edit by hand and which can contain more complex coordinates.

I just assumed the answer to this was yes but don’t we want users to stop using project.janet and move to info.jdn? Isn’t it inherently fragile to have tools edit these files with information that the user is not meant to touch even though they are editing the rest of the file?

For what it’s worth, I agree that it is nicer if the user can just call bundle/install with a path to somewhere that contains info.jdn or bundle/info.jdn but that means either: (1) you can’t have complex coordinates in :dependencies (this seems like a huge regression compared to project.janet) or (2) bundle/install needs to be able to resolve bundle names from remote locations (which I think introduces a great deal of additional complexity to boot.janet). Given that, requiring callers of bundle/install to specify :dependencies seems the preferable interface to me.

It occurred to me that a compromise might be that bundle/install could support a coordinate that includes the bundle name and a remote location. This would mean you couldn't just have a URL but I personally would find that acceptable. Something like this:

:dependencies [{:name "spork" :git "https://github.com/janet-lang/spork"}]

Would that be a better solution from your perspective?

I like the last solution, where any non-string values would be ignored by the built-in bundle/install, or we would extract just the :name key, but the extra information could still be processed by other tools. However, that also begs the question of why not just add your own custom array of external dependencies to info.jdn, say :git-deps @[{...}], or :custom-package-manager-deps @[...]. However, such a compromise would be ok to me.

Cool! I'll rework the PR.

The second commit:

1. Supports complex dependency coordinates. As proposed, it’s now possible to include a dictionary in the list of dependencies. bundle/install will pick out the value in :name and use it as the bundle name for the existence check.

2. Removes initial dependency check. The current version of bundle/install actually checks the dependencies twice. I chose the latter one to keep.

3. Tidies up code. In the original commit, I reworked some of the code to remove bits that were unnecessary and to rename some of the bindings with hopefully clearer names. I’ve kept that.

4. Shows an example. The test suite no longer needs any changes. I did make a change to example/sample-dep1/bundle/info.jdn to demonstrate a dictionary working.

LGTM. Thanks for the work, @pyrmont