Problem updating a *single* package

Hi,

I have a non registered package that I added with

] add https://github.com/.../MyPkg.git

so that when I do ] status I see:

(@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 :no_mouth:

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."

3 Likes

Yes, up MyPkg has some issues: up should support --preserve (like add) · Issue #2344 · JuliaLang/Pkg.jl · GitHub.

1 Like

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.

To bad :slightly_frowning_face:
Thanks for the clarification though.

If you are iterating in the development stage of your package, perhaps ]dev'ing and using revise would help you with your workflow.

1 Like

I do that actually, but I actually don’t do much with this specific package. Thanks though.

Just two more things to add here:

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.

1 Like

Thanks for the tips!

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 :slightly_smiling_face:

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 :sweat_smile:

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.

1 Like

Cool. I’m not familiar with PackageCompiler or sysimage but I’ll look into it.