You can instantiate a manifest without resolving it. That’s kind of the point of a manifest: it doesn’t matter how you got it, it’s a record of exactly what version you were using.
2 Likes
What I had in mind when I said Pkg.instantiateable was for the case when there is no Manifest.toml. Maybe I should have said Pkg.resolveable.
That’s why I think people should check in manifests.
Personally I do it in almost all of my projects. I even created a helper package to do this https://github.com/tkf/Run.jl.
But what I’m asking here is the consequence of current practice and implementation. Maybe describing possible problems motivate people more to check in manifests?
Another possible attack would be to shadow the name of a popular but unregistered package. For instance I did ]add Cthulhu at a time it was not registered.
Indeed. The only cure for that is registering popular packages. Another reason there should be a single central registry of public packages.
3 Likes
Is there a top secret one-liner or function to list all current packages and versions that an activated environment depends on?
Like ]st -m?
1 Like
Exactly like that SebatianM-C! Thanks!
Does anyone know if for the Compat lines we have to list versions for packages which don’t show a version number after st -m?
IE:
[2a0f44e3] Base64
[ade2ca70] Dates
[8bb1440f] DelimitedFiles
[8ba89e20] Distributed
[7b1f6079] FileWatching
[9fa8497b] Future
[b77e0a4c] InteractiveUtils
[76f85450] LibGit2
[8f399da3] Libdl
[37e2e46d] LinearAlgebra
[56ddb016] Logging
[d6f4376e] Markdown
[a63ad114] Mmap
[44cfe95a] Pkg
[de0858da] Printf
[9abbd945] Profile
[3fa0cd96] REPL
[9a3f8284] Random
[ea8e919c] SHA
[9e88b42a] Serialization
[1a1011a3] SharedArrays
[6462fe0b] Sockets
[2f01184e] SparseArrays
[10745b16] Statistics
[4607b0f0] SuiteSparse
[8dfed614] Test
[cf7118a7] UUIDs
[4ec0a83e] Unicode
if so how do we get those version numbers?
Those are the standard libraries and it is what was discussed above. Right now you don’t need to have compat bounds for them.
2 Likes
Thanks for clarifying. Well I have to say - this has been eye opening. I religiously wrote code myself rather then use other peoples packages for small routine tasks incase dependency issues broke out later(been burned from python too many times). My package which has only 11 depends needed 64 compat lines! Whew.
Scratch that - heads up to my fellow ignoramuses’ not all the packages in st -m are needed for compat. Only the ones listed in [deps] or [extras] in your toml are. It’s a pattern matching and parsing problem to do this but not too bad…
Yes, from what I understand you only need bounds for direct dependencies (]st), not all dependencies (]st -m).
2 Likes
Compat bounds are only required for your direct dependencies, by which I mean the packages listed under [deps].
Compat bounds are not required for indirect dependencies.
Compat bounds are not required for packages listed in [extras].
Compat bounds are not required for stdlibs.
2 Likes
If you make a release with Registrator, automerge will post a comment on the pull request listing all packages for which you need to add compat bounds.
So you don’t have to figure it out yourself. Just make a release, and automerge will let you know what changes you need to make.
3 Likes
Just so you know. If you add “extra” things to compat that aren’t in [deps] [extras] it will tell you them one at a time.Making you manually correct them and add then commit and push each time.
1 Like
I’m not sure what you mean. Do you have an example that you can link?
Now I see what you mean.
That is very annoying.
I have opened an issue here: https://github.com/JuliaRegistries/Registrator.jl/issues/237
1 Like
Well hopefully no one else is as daft as me - but if it fits into a priority with you all it may help someone else out :).