~dmbaturin/soupault

1

Nix derivation in the project?

Details
Message ID
<798ca62ee0cb4390ae4154a959337a4a@posteo.net>
DKIM signature
pass
Download raw message
I’ve been using `nix` and NixOS for a bit now. There’s a lot of nice 
things I could say about the experience _after_ the learning curve. 
Soupault is not a part of `nixpkgs`, but it could be. If I have the 
time, I would like to add it. There are two main routes to go about 
this:

1. have `flake.nix` and `default.nix` in the root of the project, 
maintained by Soupault’s contributors
2. build the project in `nixpkgs`, independent of here

The advantage of the first is that the derivation could be mostly 
managed inside this project and the upstream derivation would just clone 
whichever mirror with a tag/hash and run the appropriate `.nix` file. 
Updating in `nixpkgs` is now super easy and there isn’t need  for much 
discussion when a version is bumped. Another nice advantage of in 
Soupault’s repo is it being easy to flake override for local shells 
(like if updating the `nixpkgs` repo is slow or a user wants to pin an 
older version of Soupault specifically; this can be done with `nixpkgs` 
but could be more straightforward here).

The disadvantage is now this project has to maintain package management 
code for a single platform that perhaps its users don’t care to use. 
There would also be two new files to pollute the root. Follow would come 
a discussion to add Cachix to the mix to help cache new versions but 
this is more tooling and complexity (though pushing to Cachix could be 
part of the automated build step).
Details
Message ID
<5f64fa79-6938-6408-8fd7-8cc30f1945ad@baturin.org>
In-Reply-To
<798ca62ee0cb4390ae4154a959337a4a@posteo.net> (view parent)
DKIM signature
pass
Download raw message
>Soupault is not a part of `nixpkgs`, but it could be.

Agree. I definitely would like to make it easier to install for users of
different OSes/distros, it's just time and release lifecycle constraints
that prevent me from working on it (for the record, I'm a Fedora user
myself).

From a quick look at nixpkgs, all OCaml libraries required to build
soupault 2.7.0 are already there, and they seem reasonably quick to
merge pull requests if new dependencies are needed.

>The disadvantage is now this project has to maintain package management
code for a single platform that perhaps its users don’t care to use.

I would be uneasy to end up in charge of files I will not regularly test
and may not have qualification to fix if they break.
For this reason I'd prefer those packaging files to live in nixpkgs
only, where they are more likely to be cared for, even if neither you
nor I have time or motivation to maintain them.
I'm not refusing to assist with making packaging easier though!

As of installing old versions, OPAM repos contain packaging files for
every version, so even in the worst soupault/nixpkgs mess-up there's
still a reasonably easy way to compile any old version (not counting the
statically linked x86 binaries).



On 6/3/21 3:00 PM, toastal@posteo.net wrote:
> I’ve been using `nix` and NixOS for a bit now. There’s a lot of nice
> things I could say about the experience _after_ the learning curve.
> Soupault is not a part of `nixpkgs`, but it could be. If I have the
> time, I would like to add it. There are two main routes to go about this:
>
> 1. have `flake.nix` and `default.nix` in the root of the project,
> maintained by Soupault’s contributors
> 2. build the project in `nixpkgs`, independent of here
>
> The advantage of the first is that the derivation could be mostly
> managed inside this project and the upstream derivation would just
> clone whichever mirror with a tag/hash and run the appropriate `.nix`
> file. Updating in `nixpkgs` is now super easy and there isn’t need 
> for much discussion when a version is bumped. Another nice advantage
> of in Soupault’s repo is it being easy to flake override for local
> shells (like if updating the `nixpkgs` repo is slow or a user wants to
> pin an older version of Soupault specifically; this can be done with
> `nixpkgs` but could be more straightforward here).
>
> The disadvantage is now this project has to maintain package
> management code for a single platform that perhaps its users don’t
> care to use. There would also be two new files to pollute the root.
> Follow would come a discussion to add Cachix to the mix to help cache
> new versions but this is more tooling and complexity (though pushing
> to Cachix could be part of the automated build step).
Reply to thread Export thread (mbox)