It's becomes somewhat common to send just a manifest file and a source file in order to provide a MWE of a bug. In this case, the recipient of the code and manifest needs to reconstruct a project file in order to run the code in question. To facilitate this situation, I propose that we consider a directory with just a manifest file and no project file to implicitly have a project file with just a [deps] section with entries for every package in the manifest whose name is unique. This will require changes to code loading, so technically it's a Base Julia issue as well, but I figured I'd post it here first to see what people think. cc @JeffBezanson who motivated the idea for me.
A less automatic but still rather convenient way would be exposing a function that reconstructs a Project.toml from the Manifest.toml as part of the API. Given a Manifest.toml, one could just call that.
Detecting a Manifest.toml without a Project.toml while loading code in an interactive session, Julia could prompt offering to call this function.
I have been thinking about this too and my idea was to use instantiate for this (instantiate would be the API to construct the Project.toml as tpapp suggests). I think this makes sense and you can then set up an environment with any combination of the files, and the workflow would be the same no matter what combination of files you get; you always activate the project and instantiate. instantiate would then have the following behavior:
instantiate a Project.toml file creates a Manifest.toml file, resulting in an environment with Project.toml/[deps] available.instantiate a Project.toml + Manifest.toml pair results in an environment with Project.toml/[deps] available, and versions fixed by the given manifest.instantiate a Manifest.toml results in an environment with all deps in Manifest.toml available, and versions fixed.with entries for every package in the manifest whose name is unique.
With the instantiate proposal above we can (in an interactive environment) query the user for which of the deps to put in the project file.
This will require changes to code loading
One advantage of this idea is that this should not be needed.
Yes, that's an even better idea, @fredrikekre 馃榿
Most helpful comment
I have been thinking about this too and my idea was to use
instantiatefor this (instantiatewould be the API to construct theProject.tomlas tpapp suggests). I think this makes sense and you can then set up an environment with any combination of the files, and the workflow would be the same no matter what combination of files you get; you always activate the project andinstantiate.instantiatewould then have the following behavior:instantiateaProject.tomlfile creates aManifest.tomlfile, resulting in an environment withProject.toml/[deps]available.instantiateaProject.toml+Manifest.tomlpair results in an environment withProject.toml/[deps]available, and versions fixed by the given manifest.instantiateaManifest.tomlresults in an environment with all deps inManifest.tomlavailable, and versions fixed.With the
instantiateproposal above we can (in an interactive environment) query the user for which of the deps to put in the project file.One advantage of this idea is that this should not be needed.