-
Notifications
You must be signed in to change notification settings - Fork 444
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
Convert some (or all) of the automerge guidelines into hard requirements #10163
Comments
For guidelines for all registrations, I believe we had something stronger than In terms of repo URL, that makes it impossible to have multiple packages in the same repository which I thought at one points would have been supported. In terms of sequential version number, there are some instances where the benefits are non-existent but there are some issues. For example, #3011 (comment). |
@fredrikekre @mortenpi Are you opposed to making all of the guidelines required or making any of the guidelines required? |
it will be nice to have a package like GuidelineValidator.jl or even just a script to do it. Most package management apps like debian and R have some form of integrity checker. If the guidelines are clear enough to be scripted, it can help in the workflow of all. It can check for some guideline violations and suggests corrections. |
That’s exactly what the AutoMerge bot already does, right? |
The functionality for checking the guidelines already exists in: https://github.com/JuliaRegistries/RegistryCI.jl So someone would just need to develop a wrapper around RegistryCI.jl that allows you to run it locally. Alternatively, if you don’t want to run it locally, you can just make a registration, and the automerge bot will post a comment with the results. |
Are you suggesting that if users don't meet hard requirements, the PR will never be merged? My 2 cents are below:
I can see cases where the Julia package is a wrapper or a rewrite of an existing software, and following the original naming convention feels right. An example of a package I maintain is HELICS.jl and our convention is to use either all uppercase (
Do you mean sequential version numbers including the major version number? Let's say I had some git history like this:
If someone is using |
This is already allowed and is implemented in the automerge bot. |
Going forward, I think we need to prioritize standards within the Julia ecosystem over consistency with other languages ecosystems. So while there are packages in the General registry that don’t meet those guidelines, those packages are “grandfathered in” and should not serve as examples or justification for future packages. In the future, we need to enforce some standards on package names. |
Hi there, I thought it might be helpful to provide my perspective as someone from the multi-ecosystem world, since my PR #9767 appears to be what caused this issue. 😄 I'm the primary maintainer of mlpack (https://www.mlpack.org/) and our convention for many years has been to use only But @kdheepak already covered that, and really I think the more important thing to point out is increased maintainer burden, and that's what I'd respectfully like everyone to consider here. When we submitted our Python package, due to various issues we were forced to name it I see echoes of that PyPI situation here. If all Julia packages must adhere to these capitalization standards with no exceptions, this will mean that any packages like mine (and Anyway, I hope that this was helpful and provides a useful perspective. 👍 I don't think I've ever written such a long essay about ... capital letters. 😆 |
Mainly the "all" part, specifically making the naming guidelines hard requirements. Won't there always be cases where we would want to allow exceptions (e.g. HDF5)? But if we allow exceptions then it's not a hard requirement anymore? So maybe it's a bit unclear to me what "hard requirement" actually implies. |
I also never understood the "Standard initial version number" rule. I really don't see what's the problem for anyone if a new package starts from v1.2.3. I can see a lot of possible explanations to this, as uncommon as they can be. |
Alright, it looks like this idea is unpopular. I’ll leave this issue open for a little while longer, and then, unless there is a sudden wave of support for the idea, I’ll close it. |
👎 |
As a reference,
|
Currently, the official stance is that the automerge guidelines are simply guidelines. They are strongly recommended, but they are not required.
On a regular basis, registry maintainers (including myself) go through the list of open pull requests and manually merge pull requests that do not adhere to the automerge guidelines.
I think that we should convert some (or all) of the automerge guidelines into hard requirements.
Here are the current automerge guidelines. Which ones should we convert into hard requirements, and which ones should stay as guidelines?
Guidelines for all registrations:
Pkg.add("Foo")
worksimport Foo
worksGuidelines only for registrations of new packages:
/$name.jl.git where name is the package name
Guidelines only for registrations of new versions of existing packages:
Now of course I am biased. I think we should just convert all the guidelines into requirements and call it a day. But I know that not everyone will agree with that.
The text was updated successfully, but these errors were encountered: