[Nix-dev] Software development workflow -- the nix way?

[phreedom at yandex.ru]

В письме от Четверг 15 августа 2013 18:08:52 пользователь Kyle Heath написал:
> Hi Nix Folks,
> 
> *short version:*
> *
> *
> I would like to enable the following development workflow...
> 
> 1. I write packages of code containing java, c++, python binary and library
> targets (and probably host them on github)
> 2. I include with each package a build script that will provide all it's
> dependencies via nix packages - (either from the official nix repository or
> from my own public repository of nix packages)

An example of package shipping its own nix expression: 
https://github.com/phreedom/nixpkgs-monitor

You can also ship a development environment this way.

> 3. I can release source and binary versions of my packages by tagging them
> on github and publishing them to my own nix channel.  After publishing
> them, anyone can depend on them from other packages based on the same build
> script system.

Never dealt with channels :(
But you can make the binaries of your package and its dev environment 
available.

Also, while I have never tried this, you can probably write a derivation that 
fetches the required .nix file from your repository and then imports it:

  pkgnix = fetchurl { url = http://something; sha256 = "..."; }
  pkg = import pkgnix;


The problem with such an approach in general is that such a package will lose 
CI and that dependency updates become a responsibility of the package 
publisher. Developers can definitely deal with major versions of their deps, 
but how closely would developers track minor(read vulnerability and bugfix) 
updates? 

I'm not very optimistic in this regard, and suspect that  an out-of-tree 
package depending on out-of-tree package is a recipe for vulnerabilities. 

To sum it up:
1. 0install sets to make a distro-agnostic package manager
2. Enforces a specific approach to refer to dependencies(by unique ID and 
version mask)
3. primarily intended by its developers to be used without "middlemen" like a 
typical distro maintainers who do integration and security work.

[1] Same as Nix.

[2] Packages in NixPkgs use the same sloppy references to each other, which 
facilitates updates.

It is also possible to refer to a specific build script as a dependency instead 
of package name, thus wrestling away the control from distro maintainers. Nix 
can enforce such specific builds thanks to hashes.

In 0install a similar result can be obtained by hosting your own builds of 
dependencies and referring to their URL instead, although it might be 
inconvenient due to lack of tools since 0install devs probably didn't intend 
to encourage such an approach.

[3] A distro-like approach can be implemented in 0install as well, since 
anyone can publish their builds of packages and you can use them as 
dependencies instead of builds provided by the software publisher.

== short version

If you wrestle away anyone's influence on your dependencies by specifying 
hashes, you become responsible for maintenance of the dependencies.

If you let someone manage your dependencies, they need to know you exist and 
you need to trust them to care to not break your stuff(as in do CI), AND they 
need to be able to fix stuff on your side if their update exposes your mistakes.

Which, in case of core dependencies like glibc, gcc, Xorg and such, means that 
the maintainers need to have and CI all the available packages, thus this 
causes nixpkgs and hydra to emerge.



> Has anyone done something like this or have ideas if this could be done?
> 
> *long version:*
> 
> I'm a graduate student, and write lots of code that I'd love to share with
> the world.  I'm learning the hard way that publishing source is easy for
> the developer, but hard for potential users while publishing (a matrix) of
> binary versions makes it easy for potential users but really hard for the
> developer.  I started packaging my code with
> zeroinstall<http://0install.net/>, but quickly found that binary
> portability is hard to pull off and package dependency resolution based on
> ad-hoc version numbers is not good enough to reliably build software from
> source.  I read the nix papers and
> documentation and was very excited about the generality of this approach.
> I would love to figure out if nix can be part of a cross-language
> cross-platform workflow that eliminates the dependency hell problem.
> 
> Cheers,
> Kyle