Good point – thanks!
Seems like having a bin directory inside the project and put them in there would work. Did you want any functionality beyond that?
Would be awesome if github would support the Julia dependency graph for Pkg3
6 Likes
There are two orthogonal questions here:
- How does a package author indicate that their package includes some command-line tool
- What does Pkg3 do with such tools
For (1), it seems like either considering any julia files in MyPkg/bin to be such tools would be reasonable, or having it be a field in the Project.toml
For (2), one option would be to symlink/copy them into some bin folder in the Depot, (which presumably the user could add to their PATH). Another option would be to put it directly in /usr/local/bin, or some other folder that’s already on the path. The former option has the nice property that it’s cross-platform.
Both have the problem that you might have multiple different versions of a given package, so it’s not clear which should get its tools installed. Maybe there would be a separate pkg task that would install any tools for a given package.
2 Likes
I’d suggest a third option for (2): an executable (or julia switch) that dynamically alters the binary load-path in a platform-specific way such that executables stored in packages can be accessed. e.g. This is the bundle exec model for Ruby. Alternatively, we could also go full-on virtual env style, and just require that a Julia environment be “activated” before packaged binaries would work.
I actually have a script folder with the scripts inside. But, I think that It could be not so easy for non-programmer users to access them. Python’s setuptools automatically includes packages’ scripts in an executable path (e.g. /usr/local/bin using Ubuntu). Having something similar in Julia could be great. The tricky part is to support different OS and also different Julia and Julia’s package versions at the same time…
Following the doc, from directory ~/Z I have created directory HelloWorld using command pkg> generate HelloWorld.
First (small) problem, import HelloWorld is complaining “Module not found”. Doc needs improvement.
Second (worst) problem, when JULIA_LOAD_PATH environment variable is defined (here as /home/lambda/Z), packages are installed in julia-install-path/usr/local instead of ~/.julia/packages:
pkg> add JSON
Resolving package versions...
Downloaded JSON ─ v0.17.1
Updating `/local/prog/julia-master/julia/usr/local/share/julia/site/v0.7`
[682c06a0] + JSON v0.17.1
ERROR: SystemError (with /local/prog/julia-master/julia/usr/local): mkdir: Permission denied
My install is today fresh. What did I forget?
1 Like
Did you cd into the directory (like the docs say) ? This will be clearer soon since the repl prompt will show the name of the project you are currently in.
1 Like
Thanks Kristoffer, you solved my problem. I don’t need anymore to set JULIA_LOAD_PATH. I’m not immediatly concerned by the second problem. Is it a bug or a feature?
1 Like
What do package developers have to do to add support for Pkg3? Some guidelines about what files must be added/changed in currently existing package repositories would probably speed up the transition.
Reading the documentation in the Julia manual, I think I could try generate a new package for Pkg3 (with the .toml files, etc.), and copy the files of the package that was created for Pkg2 into the new folder, but I’m not sure if that’s the right way to proceed.
You will only need to add a Project.toml file but we will try to make PRs to registered packages to do this and some tool in Pkg3 to upgrade the package.
6 Likes
I had an issue with including a Project.toml file with dependencies in Pkg2. It would break my package as it would not find the dependencies. I am in process of registering it with Metadata and will upgrade it at a later stage.
My pull request in Pkg3 provides the pkgsearch functionality that finds all dependencies of packages using the new metadata. However, nobody has reviewed my PR yet, but the feature exists on my branch.
3 Likes
I added next comment to 26680 issue:
‘Maybe Tk has to be removed from official repository and Pkg3/Pkg has to inform about this “banning” process and propose to uninstall it.’
Maybe will not agree about Tk, but possibility to warn and remove dangerous packages in the future could be nice feature.
What do you think?
PS. BTW @quinnj closed this issue as something which doesn’t belong to Julia itself, but I am afraid we have not to underestimate security problems like this.
The Pkg3 Manifest.toml file contains all packages for the project and what versions they are installed at. And if someone gives you a Project.toml + Manifest.toml you can “instantiate” that exact environment.
Pkg3 Project + Manifest give you the environment of the project, but it might be nice to have a way to report the information of the session at that instance. For example, before loading a package vs after loading all packages. One practicality would be not having to have a sanitized project environment for a short piece of code that only depends on a couple of packages while working on a project with several dozen that may be irrelevant for that particular piece of code. I believe those are two related, but different solutions (e.g., R’s sessionInfo vs packrat).
I just had the case that I was editing the installed SHA package and my edits did not change anything. Then I found out that SHA was added to stdlib. Will Pkg3 allow a local package to take priority over one from stdlib?
This is more a matter of how Julia itself is built and loads code, not the package manager. Currently you cannot change the version of stdlib packages but in future versions of Julia you will. (As I wrote above.)
what if there is no version of stdlib without SHA?