[Nix-dev] Package coding standards (was Re: Separating Free/non-free package)

[Eelco Dolstra]

Hi all,

Ludovic Courtès wrote:

> Eelco Dolstra <e.dolstra at tudelft.nl>
> writes:
> 
>> - A while ago I did some work on a "virtual RMS" for Nix, though I didn't get
>> very far.  The idea is that you can say
>>
>>   $ nix-vrms /etc/nixos/nixos -A system
> 
> That sounds cool.  Where can we get it?

It's vapourware.  Like I said, I didn't get very far :-)

I'll try to finish a simple prototype.

>> - I'm not so worried that the meta.license field will be incorrect (just
>> missing, but that's a matter of policy - we can require it for all new
>> packages).
> 
> Unfortunately, that there’s been no such policy for years makes
> ‘meta.license’ essentially unusable.  It’s also been argued that the
> recommendations in ‘meta.xml’ are way too vague.  And it appears that,
> e.g., Nicolas, would consider “free” in the sense of “gratis”, which
> adds to the confusion.

Then the description needs to be improved.  (If it's gratis but not free, it
should be "unfree-redistributable".)

> So I’m glad if a policy is instated and actually followed.  However I’m
> afraid it’d happen too late and would be foreign to most contributors.
> Nixpkgs contributors have been used to “free-style” cooperation, a
> custom that’s going to be hard to change IMO (think ‘builderDefs’
> vs. ‘stdenv’, ‘pythonNew’ vs. ‘python’, ‘args: with args;’, etc., etc.).

It's good to provide opportunity for experimentation, but I think that now we
need some package coding standards.  In particular:

- Packages should have a consistent external calling interface.  I.e., "import
./pkg.nix { ... deps ... }", not (for example) "builderDefsPackage
(selectVersion ./dir "1.8") { ... deps ... }", as this exposes implementation
details.

- There are a number of alternative styles of writing packages than the old
stdenv.mkDerivation, such as builderDefs and composableDerivation.  We should
think about what works and merge it into stdenv.mkDerivation.

- Customization should be done consistently.  For instance getConfig is used
kind of arbitrarily in all-packages.nix.  Also, some packages have ad-hoc
mechanisms for external customisation (e.g. the nixUnstable function now has
"nameSuffix" and "patches" arguments), but there are more general ways to do that.

- Some guidelines with respect to versioning (e.g. when to keep expressions for
old versions around, and how to name them).

Comments welcome.

>> The solution is to finish the virtual RMS tool and add missing
>> meta.license fields :-)
> 
> Is VRMS able to analyze SWIG’s license [0]?  Real life is full of
> examples like this one.

VRMS wouldn't analyse any software, it's up to the packager to correctly
classify the package.  For complicated licenses, that's what the "free" and
other catch-all license values are for.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/