Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add automatically compat entry when adding a dependency to non-package projects #4069

Open
giordano opened this issue Nov 1, 2024 · 3 comments · May be fixed by #4101
Open

Add automatically compat entry when adding a dependency to non-package projects #4069

giordano opened this issue Nov 1, 2024 · 3 comments · May be fixed by #4101

Comments

@giordano
Copy link
Contributor

giordano commented Nov 1, 2024

#3732 enabled automatic addition of compat entries when adding a new dependency to a package project, but I believe we should do that for all environments, or at least the non shared ones. Manifests are certainly useful when you have a fixed pipeline which is always running with a fixed version of Julia, but in other cases they're more annoying to carry around, as they are julia version-specific. Now we have versioned manifests which help in certain situations, but do absolutely nothing for instantiating a compatible project in one or two year time with a version of julia which didn't exist when one first created the environment.

Certainly the risk of this proposal is for compat bounds to go stale over a long time, but I think that ensuring that instantiating an environment with (presumably) compatible packages at a later time outweighs the benefit of always having the super latest version of all packages which comes with the risk of breaking the workflow anyway. Automatically adding compat bounds on all non-shared environments would help promote this practice.

@IanButterworth
Copy link
Member

Seems reasonable to me.

@giordano
Copy link
Contributor Author

How to distinguish a "shared" environment from other non-named non-UUID'ed environments? I was looking at implementing this, but I don't know how to do it.

@giordano
Copy link
Contributor Author

Searching for "shared" in this repo I got the feeling that a "shared" environment isn't a property of an environment, but merely a convenience concept? Looking at

function _shared_envs()
possible = String[]
for depot in Base.DEPOT_PATH
envdir = joinpath(depot, "environments")
Base.isaccessibledir(envdir) || continue
append!(possible, readdir(envdir))
end
return possible
end
a shared depot should be identified by whether it lives in the environments subdirectory of a depot?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants