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

fix finding bundled stdlibs even if they are e.g. devved in an environment higher in the load path #52637

Merged
merged 1 commit into from
Jan 5, 2024

Conversation

KristofferC
Copy link
Member

I noticed this when seeing some weird precompile issues when I had SparseArrays devved in my main environment but it was with the standard stdlib format in the current environment:

(NearestNeighbors) pkg> st -m
Project NearestNeighbors v0.4.15
Status `~/JuliaPkgs/NearestNeighbors.jl/Manifest.toml`
...
  [2f01184e] SparseArrays v1.10.0 
...

But even so, locate_package claims that the path to SparseArrays is the one in the main environment:

julia> pkg = Base.PkgId(Base.UUID("2f01184e-e22b-5df5-ae63-d93ebab69eaf"), "SparseArrays")
SparseArrays [2f01184e-e22b-5df5-ae63-d93ebab69eaf]

julia> Base.locate_package(pkg)
"/home/kc/JuliaPkgs/SparseArrays.jl/src/SparseArrays.jl"

This correctly fixes it so that packages without a git-tree-sha1 (and without a path) are resolved to the stdlib path.

@KristofferC KristofferC added the packages Package management and loading label Dec 27, 2023
@KristofferC KristofferC added the backport 1.10 Change should be backported to the 1.10 release label Dec 27, 2023
@KristofferC KristofferC mentioned this pull request Jan 5, 2024
33 tasks
@vtjnash vtjnash merged commit c9bc2ff into master Jan 5, 2024
9 checks passed
@vtjnash vtjnash deleted the kc/fix_finding_stdlibs branch January 5, 2024 15:45
@vtjnash
Copy link
Member

vtjnash commented Jan 5, 2024

This had confused me too, so thanks for figuring out what was needed to make it work

KristofferC added a commit that referenced this pull request Jan 24, 2024
…an environment higher in the load path (#52637)

I noticed this when seeing some weird precompile issues when I had
SparseArrays devved in my main environment but it was with the standard
stdlib format in the current environment:

```
(NearestNeighbors) pkg> st -m
Project NearestNeighbors v0.4.15
Status `~/JuliaPkgs/NearestNeighbors.jl/Manifest.toml`
...
  [2f01184e] SparseArrays v1.10.0
...
```

But even so, `locate_package` claims that the path to SparseArrays is
the one in the main environment:

```
julia> pkg = Base.PkgId(Base.UUID("2f01184e-e22b-5df5-ae63-d93ebab69eaf"), "SparseArrays")
SparseArrays [2f01184e-e22b-5df5-ae63-d93ebab69eaf]

julia> Base.locate_package(pkg)
"/home/kc/JuliaPkgs/SparseArrays.jl/src/SparseArrays.jl"
```

This correctly fixes it so that packages without a `git-tree-sha1` (and
without a `path`) are resolved to the stdlib path.

(cherry picked from commit c9bc2ff)
KristofferC added a commit that referenced this pull request Feb 6, 2024
Backported PRs:
- [x] #51095 <!-- Fix edge cases where inexact conversions to UInt don't
throw -->
- [x] #52583 <!-- Don't access parent of triangular matrix in powm -->
- [x] #52645 <!-- update --gcthreads section in command line options -->
- [x] #52423 <!-- update nthreads info in versioninfo -->
- [x] #52721 <!-- inference: Guard TypeVar special case against vararg
-->
- [x] #52637 <!-- fix finding bundled stdlibs even if they are e.g.
devved in an environment higher in the load path -->
- [x] #52752 <!-- staticdata: handle cycles in datatypes -->
- [x] #52758 <!-- use a Dict instead of an IdDict for caching of the
`cwstring` for Windows env variables -->
- [x] #51375 <!-- Insert hardcoded backlinks to stdlib doc pages -->
- [x] #52994 <!-- place work-stealing queue indices on different cache
lines to avoid false-sharing -->
- [x] #53015 <!-- Add type assertion in iterate for logicalindex -->
- [x] #53032 <!-- Fix a list in GC devdocs -->
- [x] #52748 
- [x] #52856 
- [x] #52878
- [x] #52754 
- [x] #52228
- [x] #52924
- [x] #52569 <!-- Fix GC rooting during rehashing of iddict -->
- [x] #52605 <!-- Default uplo in symmetric/hermitian -->
- [x] #52618 <!-- heap snapshot: add gc roots and gc finalist roots to
fix unrooted nodes -->
- [x] #52781 <!-- fix type-stability bugs in Ryu code -->
- [x] #53055 <!-- Profile: use full terminal cols to show function name
-->
- [x] #53096 
- [x] #53076 
- [x] #52841 <!-- Extensions: make loading of extensions independent of
what packages are in the sysimage -->
- [x] #52078 <!-- Replace `&hArr;` by `&harr;` in documentation -->
- [x] #53035 <!-- use proper cache-line size variable in work-stealing
queue -->
- [x] #53066 <!-- doc: replace harr HTML entity by unicode -->
- [x] #52996 <!-- Apple silicon has 128 byte alignment so fix our
defines to match -->
- [x] #53121 

Non-merged PRs with backport label:
- [ ] #52694 <!-- Reinstate similar for AbstractQ for backward
compatibility -->
- [ ] #51479 <!-- prevent code loading from lookin in the versioned
environment when building Julia -->
@KristofferC KristofferC removed the backport 1.10 Change should be backported to the 1.10 release label Feb 6, 2024
Drvi pushed a commit to RelationalAI/julia that referenced this pull request Jun 7, 2024
…an environment higher in the load path (JuliaLang#52637)

I noticed this when seeing some weird precompile issues when I had
SparseArrays devved in my main environment but it was with the standard
stdlib format in the current environment:

```
(NearestNeighbors) pkg> st -m
Project NearestNeighbors v0.4.15
Status `~/JuliaPkgs/NearestNeighbors.jl/Manifest.toml`
...
  [2f01184e] SparseArrays v1.10.0
...
```

But even so, `locate_package` claims that the path to SparseArrays is
the one in the main environment:

```
julia> pkg = Base.PkgId(Base.UUID("2f01184e-e22b-5df5-ae63-d93ebab69eaf"), "SparseArrays")
SparseArrays [2f01184e-e22b-5df5-ae63-d93ebab69eaf]

julia> Base.locate_package(pkg)
"/home/kc/JuliaPkgs/SparseArrays.jl/src/SparseArrays.jl"
```

This correctly fixes it so that packages without a `git-tree-sha1` (and
without a `path`) are resolved to the stdlib path.

(cherry picked from commit c9bc2ff)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages Package management and loading
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants