Add a model for package

[florentc]

As a step to implement #532, this WIP PR introduces a db model for packages. For now, a package only has a name. The nix derivation table gains a column, package, for the many-to-one relation from derivation to package. The provided migration ensures the creation of packages associated to all derivations and links each derivation to the right package.

The idea is that user profiles will be in relation with packages to model subscriptions. This will make it possible to subscribe to a package name as we discussed with @fricklerhandwerk and make queries easier to link a "package" and the many derivations. Eventually, we could envision to migrate some metadata from derivations, which are in fact shared and package-related, to this package model.

[fricklerhandwerk]

This will probably stop the world for a long time

[florentc]

It did take something like 5 min. Do you know how it could be optimized?

[fricklerhandwerk]

Generally something like here: https://github.com/Nix-Security-WG/nix-security-tracker/pull/538/files

But see my top level comment for why we may not need that anyway

[florentc]

@fricklerhandwerk I wanted your opinion/advice about implementing setting up the package of a derivation automatically and eventually making the package field non nullable. What would be the go-to way to automatically get_or_create a package and assign it to the package field?

Should I override the save method of the model or use some signal (post_save or other?) or something else

This would look something like this in both cases:

package, _ = NixPackage.objects.get_or_create(name=self.attribute)
self.package = package

[fricklerhandwerk]

To be honest, I don't know, but I agree we'd need something like that.

Although I wonder whether it's a good idea to store the "package" aggregation at the relational layer. We need that information very quickly for (anything like) search (#215), so it needs to be cached anyway. So why not instead let the NixPackage model have a nullable JSONField that would store the derivations already together with whatever data we need, channel and version in particular? Then we could populate it on first access (e.g. when it's None and then update whenever a new NixDerivation is ingested, which would need a post_save signal on NixDerivation). At least for now, or maybe we'd do a management command that would populate the cache, just like with suggestions.