(@v1.6) pkg> status
[...]
MyPkg v0.1.0 `https://github.com/.../MyPkg.git#main`
Now, I work on the package a bit and want to get the updates in my base environment, so I do:
(@v1.6) pkg> up MyPkg
However, what happens is that all packages are updated. Why??
According to The Pkg.jl Documentation this is what I need to do.
The issue is, that I also have packges like Plots.jl in my base environment, and when they update, downloding the GR artifact and compiling GR_jll takes around 5 minutes
What am I doing wrong? not understanding? etc.
Thanks!
Note: this MyPkg is very light weight so it is not as if it should have any dependency conflicts…and besides that seems to not be relevant since in the Pkg Documentation it states:
" If Example has a dependency which is also a dependency for another explicitly added package, that dependency will not be updated."
Why isn’t preserve the default for both? For me this has been a considerable headache, given that my internet connection is less than ideal many times.
I’m asking out of sincere curiosity about the design decision that led to this behavior.
In my humble opinion, adding or updating a single package should only update the necessary dependencies and whatever else needed for dependency consistency, but nothing else. Currently inadvertently as adding or updating even a dummy package triggers updating everything.
Am I understanding this comment from @oxinabox that if I ] up MyPackage@0.1.0 I actually would get the behavior that I want? Or is it currently simply not possible to update a single package?
It is not currently possible.
That command with update that package with restrictions.
But will leave all other packages not mentioned as unrestricted and allow them to update freely.
Current behaviour is pretty unintuitive, and not very useful.
First, don’t add packages to your default environment unless they are dev packages like Revise, Pluto etc. Use project environments instead, where you only add the packages relevant to a specific bit of analysis. In that way updating the environment does not affect completely unrelated packages used for other purposes in other environments.
Second, you can pin packages in an environment to ensure up doesn’t affect them.
I like the pin option with the one downside that it sort of works in reverse: instead of saying “please only update this package” it says “do not update this one”
As to adding packages to the base environment: I struggle here.
My main issue is with how long it takes Plots.jl to update (at least that seems to be what’s causing must of the delays).
I’m of the opinion, however, that Plots.jl should not be a package dependency if that can be avoided, since
A) it’s big and
B) the analysis and how it is presented usually can and should be separated.
Granted, if I never work in the base environment, then Plots.jl will never update
Finally, the specific package that motivate this thread is essentially something to save various templates and as such doesn’t really helping in any one specific project.
I didn’t mention that though because I don’t think my specific use case is that important to the general public
That’s entirely fair, I actually have Plots and DataFrames in my default environment as well given how often I’m doing something just to answer questions on here or SO that involve those packages.
A very specific solution to this issue then would be to just make a sysimage with PackageCompiler that has Plots in it. That way you’d only spend 10 minutes once every few weeks or months re-compiling with a new Plots version when you need it and otherwise have instantaneous startup (and plotting!) speed without any recompilation issues in between.
