Convert some (or all) of the automerge guidelines into hard requirements about general HOT 15 CLOSED

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 mlpack. This is pretty important for branding. So, just like the HELICS project, it would be a little bit confusing for a user familiar with the package to suddenly need to type using Mlpack or Pkg.add("Mlpack") when, in other languages we support, mlpack is used. It might seem trivial (it's just a single capital letter after all!) but in my experience these types of things do raise very real extra barriers for, e.g., users of a multi-ecosystem package who want to try it from Julia.

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 mlpack3 in PyPI instead of mlpack. (This has since been fixed, but it took a long time.) What ended up happening was a lot of user confusion---although we did our best to document that the command to install from PyPI was pip install mlpack3, even on our 'quickstart' pages, we still received frequent bug reports and chat comments of the form "pip install mlpack didn't work, what do I do?" While the question is easy to answer, that did siphon resources from our already-stretched maintainer community.

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 HELICS and others) will have to accept the increased maintenance burden of handling user confusion from the different names that are in use for different languages.

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

from general.

Are you opposed to making all of the guidelines required or making any of the guidelines required?

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.

from general.

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.

from general.

For guidelines for all registrations, I believe we had something stronger than Base.isidentifier.

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

from general.

@fredrikekre @mortenpi Are you opposed to making all of the guidelines required or making any of the guidelines required?

from general.

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.

from general.

It can check for some guideline violations and suggests corrections.

That’s exactly what the AutoMerge bot already does, right?

from general.

https://github.com/Debian/lintian

from general.

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.

from general.

Are you suggesting that if users don't meet hard requirements, the PR will never be merged? My 2 cents are below:

Normal capitalization

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 (HELICS) or all lowercase (helics). It would be odd for a user familiar with the other tools in the ecosystem (HELICS has bindings in Python, MATLAB, Java, C# etc) to see Helics.jl. I'm pretty sure I would be able to cherry pick more examples like this from the Julia ecosystem.

Sequential version number

Do you mean sequential version numbers including the major version number?

Let's say I had some git history like this:

* 64c5540 - (tag: v0.5.1) (3 months ago)
* 1e57c55 - (3 months ago)
* 3d7e6a1 - (3 months ago)
* 555137c - (3 months ago)
* 5144fea - (tag: v0.5.0) (3 months ago)
*   93110f7 - (3 months ago)
|\
| * fd500c4 - (3 months ago)
| * a7d0804 - (3 months ago)
| * 4c5c987 - (3 months ago)
|/
* 2c90a28 - (4 months ago)
* f421dc4 - (tag: v0.4.1) (4 months ago)
*   f5b6a61 - (4 months ago)
|\

If someone is using v0.4.1 and finds a bug, I may checkout the tag v0.4.1 as a branch, make a commit to fix it (cherry pick the fix on master) and tag a new bug fix release v0.4.2, with the previous most recent tagged release being v0.5.1. I wouldn't be able to suggest that users use the latest release since that would be a breaking change.

from general.

If someone is using v0.4.1 and finds a bug, I may checkout the tag v0.4.1 as a branch, make a commit to fix it (cherry pick the fix on master) and tag a new bug fix release v0.4.2, with the previous most recent tagged release being v0.5.1. I wouldn't be able to suggest that users use the latest release since that would be a breaking change.

This is already allowed and is implemented in the automerge bot.

from general.

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 (HELICS) or all lowercase (helics). It would be odd for a user familiar with the other tools in the ecosystem (HELICS has bindings in Python, MATLAB, Java, C# etc) to see Helics.jl. I'm pretty sure I would be able to cherry pick more examples like this from the Julia ecosystem.

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.

from general.

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.

from general.

👎

from general.

As a reference,
The official documentation (Package naming guidelines) does indicate that external libraries should conform to the branding of the projects,

Packages that wrap external libraries or programs should be named after those libraries or programs.

CPLEX.jl wraps the CPLEX library, which can be identified easily in a web search.
MATLAB.jl provides an interface to call the MATLAB engine from within Julia.

from general.