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
[RFC] Packages in subdirectories need more registry information #30
Comments
I prefer option 2 with the path entry. However, I don't think you technically need this: you can search the cloned repo for a project file with the correct UUID and that tells you where it is. |
No, it is not technically necessary, but as I wrote:
|
Fair enough. So option 2 with explicit |
Although note that it's not necessary when just installing a package because the package version is associated with a git tree, which need not be at the root of the repo (which you also noted). |
What's wrong with this? it will usually be just one or two directories deep. |
It's not unrealistic that people place dozens of packages in one repository and you would have to parse lots of project files, or you are unlucky and add a branch where your project file has been removed, which you won't know until you have searched through the entire repository. But pathological cases aside, it's really about code complexity. If I were to implement it I'd much prefer to look up the path in the registry and go straight at the project file than having to traverse the file system and see if something matches. |
FWIW; I think a |
Another thing to discuss is how you register/tag a subdir package. Something like |
I'd second that As a use, I'd also be happy with the This syntax would then also be amenable to generalization: |
How about registering any directory whose project file has been changed? Although that leaves questions: changed in the last commit or at any point (since when)? Changed in any way or just the version number? So perhaps being explicit about it is better. However, the way that I usually do releases is to make a commit directly on master changing only the version number in the project file and then triggering registrator on that. If others do the same, then taking what directories to register from the triggering commit and including those with project files with changed version numbers would be pretty convenient. |
For what it's worth, LocalRegistry will do registration of packages in subdirectories exactly like normal packages. In an environment where you have |
If there are no objections, I'll merge #31 tomorrow. |
As discussed in JuliaLang/Pkg.jl#1251, having registered packages in a subdirectory of a git repository works partially today. If you prepare a registry with the right tree hashes,
add Package
andadd Package@revision
work out of the box. Additional Pkg functionality is added in the WIP PR JuliaLang/Pkg.jl#1422.However, for
add Package#branch
ordev Package
there is no information available in the registry about the subdirectory. Thus either Pkg would have to hunt through the repository for a matchingProject.toml
or the user would have to provide the subdirectory path for these operations. Neither of these options seems very satisfactory.My proposal is that
Package.toml
is modified to include this information. Two possibilities are to change (in a hypothetical world where RegistryTools lives in a subdirectory) today'sinto either
or
Both of these would be backwards compatible with current Julia versions since no changes are required for normal packages. For packages in subdirectories they differ in how they don't work properly beyond
add Package
andadd Package@version
. In the former case, as well as without path information in the registry,add Package#branch
anddev Package
downloads/clones the top level repository and end up with a broken package. In the latter case these operations instead result in an immediate, though not very clear, error.Note that packages in subdirectories is a useful enough feature that it would be worth using even without improved Pkg support. It would be good to settle this issue right away though, since adding path information to existing registries with such packages would be an unnecessary complication.
Opinions?
The text was updated successfully, but these errors were encountered: