Package Labels
Problem to solve
Currently, we are lacking a way to mark packages for internal purposes.
For example, mark a package that is currently being processed by a background job (see nuget packages).
In addition, upcoming updates on the packages UI will need to display different labels such as stable
, broken
, ...
We already have tags but currently tags are used within package managers. For example, using npm
CLI, we can tag a package version (see https://docs.npmjs.com/cli/dist-tag). As such, it would be wiser to not use tags for these internal purposes.
Proposal
- Have a
Packages::Label
model thatbelongs_to
a package. - This way a package can have multiple labels.
- Labels can then be used for package selection in the API or UI. (example: don't display or return packages that have label
processing
in the UI or API). - Some labels could also be displayed (
stable
,broken
, ...) - Currently, we could implement package label as a simple title but other fields could be interesting in future such as color or icon.
- In order to keep things simple, we could start by having a title as a enum so that the available titles is a limited set.
Immediate use
Nuget packages are uploaded without any identification (no package name or version). Those packages need to be saved and processed by a background job. During this processing, the package must not be used/returned by the UI or API. Currently, the uploaded nuget package has a fixed name and we use this fixed name to filter them from the API/UI. This is error prone and doesn't properly ensure that it's not used by the API/UI (imagine the case where a user uses a package name which is the same as the fixed one).
By using labels, we could "mark" those nuget packages as "being processed" or "not ready". We could then exclude them from the API/UI independently from the package name. This is a far more robust selection.