As part of my research I have been exposed to many package management systems for various languages and wanted to share some cool features I think would greatly benefit Julia. Some of the features are in the works with the package manager.
- PackageEvaluator.jl provides a data on continuous integration for packages (Probably the most advanced implementation of its kind)
- A few things that could be improved taking PyPi as a model (check out the classifier categories)
- Project Status (required tag: Planning, Pre-Alpha, Alpha, Beta, Production/Stable, Mature, Inactive, Unmaintained, Depreciated => and a way to depreciate packages)
- Github license system is not perfect and having a better way to track it would be nice
- CRAN like
CITATION
file which can have data such as contributor and roles
- While federalized registries have bunch of advantages it is also nice to centralize a few things
- Social or review system for packages (Could be something like Registry/PkgName)
- Download statistics
- A way to get the universe of public registries (handling duplicates)
2 Likes
One issue I’ve seen is the way the results from PackageEvaluator.jl are used for pkg.julialang.org, with no distinguishing between long abandoned packages and ones that are already working without deprecations on master.
Maybe your status information of Inactive, Unmaintained, Deprecated could be used to prune that list, to give more meaningful results when browsing packages.
1 Like
That is very true. My preliminary analysis found four packages that were depreciated (given by the description), a few others that redirect to JuliaArchive (deprecated) and over 500 packages that never had a working (i.e., passed tests) release for a supported version (i.e., currently Julia v0.6). There were also a few issues with outdated metadata and redirects with the wrong owner/repository.
1 Like
Also, hope there will be CLI commands like all other package managers. (which might not be possible recently since it still has a long start time.)
2 Likes
Once you start Julia, it’s just a matter of hitting ]
to get into the Pkg REPL.
It’s pretty convenient.
1 Like
Yeah, but currently, since packages like Revise.jl will not work when there is macros or code generation. I still need to exit REPL and restart it frequently, sometimes… Pkg mode is great, but I mean if there is CLI tools it would be much better, since REPL is not actually as powerful as a system shell and sometimes we just want to use the julia
command directly. like julia script.jl [some-parameters]
. I asked this in Pkg3 issue, they actually had a CLI, but it was removed because pure Julia is still too slow for a CLI command (because of some overheads). I believe we will have one in near future.
1 Like
Revise.jl seems to update methods created with code generation just fine when I use it. It only has a problem with it when I redefine a const
array that has a list of Symbols which the code generation depends on, that’s the only case where I currently have issue with Revise updating the generated code.
You are right.
However, types, type alias and explicit declared constants are all constant
. Therefore when you generate code about those you will probably receive a failure. And in fact, sometimes, because the lack of inheritance, we have to generate some types. (may not be recommended but just have to). e.g we were writing a framework for simulating circuits and we have some elementary gate types. we generated that part. I used revise by default in my juliarc.jl, and then I found it won’t work and slows my REPL down, so I have to exit REPL delete it from juliarc.jl and start again…
Moreover, when you use revise, it actually just updates the declaration, but it won’t delete the old one. Sometimes, this influence your dispatch behavior and you just don’t notice it… This is quite dangerous sometimes.
Finally, when you want to work with other languages, like python
, C/C++
, Go
, Rust
, it will be a quite inconvenient since even there is shell mode, you cannot use it like a shell, because it exits after each command and each command is slower than system shell for the first run. And other language can not call/config your julia environment/package/script with a sub-process (they cannot use Pkg).
I don’t think this is urgent, but I do think this is necessary. I believe I am not the only one feels that we are lack of CLI tools. And I believe the only reason we can only use them in REPL at the moment is because of the start time which will be solved in near future.
1 Like