Pkg.jl: implicit roots for manifest without project

Created on 27 Feb 2019  路  3Comments  路  Source: JuliaLang/Pkg.jl

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.

enhancement feature request

Most helpful comment

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:

  1. instantiate a Project.toml file creates a Manifest.toml file, resulting in an environment with Project.toml/[deps] available.
  2. instantiate a Project.toml + Manifest.toml pair results in an environment with Project.toml/[deps] available, and versions fixed by the given manifest.
  3. 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.

All 3 comments

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:

  1. instantiate a Project.toml file creates a Manifest.toml file, resulting in an environment with Project.toml/[deps] available.
  2. instantiate a Project.toml + Manifest.toml pair results in an environment with Project.toml/[deps] available, and versions fixed by the given manifest.
  3. 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 馃榿

Was this page helpful?
0 / 5 - 0 ratings