Comments (15)
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 tagv0.4.1
as a branch, make a commit to fix it (cherry pick the fix onmaster
) and tag a new bug fix releasev0.4.2
, with the previous most recent tagged release beingv0.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 seeHelics.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.
Related Issues (20)
- Error: TagBot experienced an unexpected internal failure HOT 1
- Gadfly v1.4.0 ? HOT 1
- over 1000 packages starting with `S` HOT 3
- JET versions before 0.8.28 are not compatible with Julia 1.11 HOT 8
- Streamline retroactive compat bounds adjustment HOT 1
- Allow auto-merge from PRs made on fork of General HOT 2
- Recommend for, or at least against, some OSI licences? E.g. against Apache 2.0 HOT 2
- what is the stopwatch mechanism for? HOT 1
- Create CI status for StorageServer caching
- Time to start subdividing within letters `S/o/SomePackage.jl` etc HOT 3
- URL change TMLE.jl
- Unable to register: Version v0.1.0 already exists
- Packages without current source of licenses HOT 18
- "not able to load the package" due to PyCall/Conda problems HOT 3
- Your `new package` pull request does not meet the guidelines for auto-merging. Please make sure that you have read the [General registry README](https://github.com/JuliaRegistries/General/blob/master/README.md) and the [AutoMerge guidelines](https://juliaregistries.github.io/RegistryCI.jl/stable/guidelines/). The following guidelines were not met:
- yank NCDatasets 0.13.0 HOT 2
- Not able to register because of lack of upper-bound for releases of LinearAlgebra HOT 6
- Update stdlib compats of JLLs
- Broken link to package naming guidelines in README
- Add CI jobs for Julia v1.10 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from general.