Are our current naming conventions for the Package Registry too strict?
Problem Statement
As a user of the GitLab Package Registry, which includes integrations with Maven, NPM, Nuget, and Conan, I find the naming conventions and scopes required quite difficult to use and understand.
Problems
- The first time this impacts me is when I am migrating from an existing package manager solution to GitLab. Because GitLab has strict naming requirements, I have to update all of my package names and configurations to match GitLab's requirements.
- It's also common for GitLab's naming and scoping requirements to not match the requirements of the specific package manager format. For example, NPM does not allow capital letters, but GitLab does.
- It's confusing that each format in the registry has different requirements for how packages should be named.
Ideal feature
- Ideally, I would like to not have any naming restriction on package names, except for not allowing duplicate uploads.
- I'd like to be able to easily connect to my remote repositories, such as npmjs.org or mvnrepository.org, or paid vendors such as Artifactory and Sonatype. = I'd like GitLab to pull from both my local GitLab repository, my remote repository, and cache both in a virtual repository, so that I don't have to download packages every time.
Reach
3.0 = Significant reach (~25% to ~50%)
- This impacts all current and future users of the Package Registry.
- It greatly impacts customers that are looking to migrate from an existing vendor, like Sonatype, to GitLab.
- The problem will continue to get more complicated as we continue to add support for additional package manager formats.
Personas
Primary personas
Secondary personas
Data
- Data is limited to GitLab.com and does not include self-managed instances.
- For all package types, we currently see about 2500 packages pushed to the registry each day
- For all package types, we currently see about 10,000 packages pulled per day.
Impact
2.0 = High impact
There are a few different ways that we can have a significant impact on GitLab's business by solving this problem.
- We help our customers transition off of their existing package manager vendor into GitLab. This would mean canceling expensive contracts with companies like Jfrog and Nexus.
- Aside from being a value for our customers, this would also help us to create a more sticky product, and drive up retention rates.
- This would make for easier adoption and use of GitLab CI/CD, as it will be much easier to use pipelines and features like the Dependency Proxy.
Confidence
This problem has been raised by several of our customers and users and expressed in a variety of ways.
Quotes
- "No developer is thinking to name their java dependencies "com/acme/my-group/my-sub-group/myproject/name" it's inefficient and results in messy code.
- "I don't understand the difference between project/group/instance level endpoints?
- "Why doesn't GitLab match NPM's requirements
- "If I use GitLab, I can't use another remote with the same scope"
- "The Naming convention that is enforced is highly impractical"
- "Currently, the organization scope of an NPM package is determined by convention: the name of the top-level project. This is detailed in the NPM package naming convention. This can be a problem for corporate development organizations where the project might be the company name and cannot be changed, while the NPM organization might be something else, like an acronym of the company name. In our case, we are migrating a lot of (hundreds) of projects to Gitlab, where all imports of our NPM packages reference the organization scope we have used until now. The top-level project in Gitlab however, is set to our official company name and cannot be changed to what we were using as our NPM organization scope. Right now I only see the solution: changing the thousands of imports in our code to the new NPM scope automatically set by Gitlab."
100% = High confidence
Effort
This will take a fairly significant effort, but it's better to solve it now, prior to adding support for another dozen package manager formats.
Research and validation
- 2 people / .5 months
Initial design
- 3 people / 1 months
Implementation
- It probably makes sense to prioritize this work by package manager formats. Starting with the most widely used down to the least used. As an estimate, without input from engineering, it might take us 1 milestone per repository to change how we handle naming and scoping.
Edited by Tim Rizzi