mixxx icon indicating copy to clipboard operation
mixxx copied to clipboard

Make shell.nix to be only a development environment

Open matthiasbeyer opened this issue 2 years ago • 8 comments

Superceeds #3795 Closes #3795

So after the suggestion by @daschuer which are quite right, this is my take in transforming the shell.nix file into a development environment helper.

I will maintain this file from this PR on.

matthiasbeyer avatar Jan 18 '22 09:01 matthiasbeyer

I'd prefer if this file was maintained outside the Mixxx repo. Maybe the nixpkgs repo would be willing to add an additional mixxx-git package that provides the latest dev version (using something like update-nix-fetchgit)? Or it could be maintained in a fork of that repo. An alternative would be to put the instructions into the wiki.

In my opinion, the mixxx repository should only contain files for the officially supported platforms (Windows/macOS/Ubuntu). Other flavors of Linux have to adapt and should to be maintained externally.

For example, I'm maintaining an ArchLinux AUR package over here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mixxx-git And @uklotzde maintains the Fedora package here: https://pkgs.rpmfusion.org/cgit/free/mixxx.git/tree/mixxx.spec

The reason is that we cannot add configuration files and CI for every distro out there. Our CI queue can already grow quite long, and in case the CI build breaks, nobody from the core team can fix the issue. We'd have to wait until you have time to take care of it (which blocks our development progress) or just ignore the broken CI jobs (also bad and makes people become used to ignoring failing checks).

If you would be willing to maintain it externally, we could mention it in the wiki so that other nixOS users can make use of it, too.

Holzhaus avatar Jan 18 '22 09:01 Holzhaus

The shell.nix file has nothing to do with NixOS, it is the development setup for mixxx which is distro-agnostic!

matthiasbeyer avatar Jan 18 '22 10:01 matthiasbeyer

How often should I explain this again, nix is not a distribution. If you package an AUR packages, you are packageing for one distribution. Nix is a isolated, self containing build system/package system that can run on any unix like system. The difference is, that nix allows me to compile/run and test any repository with one command together with ALL dependencies in a reporduceable build. This is something no other system can and actually makes development much, much easier. If dependiencies change, I don't even notice when building/running any checkout. The system just does the right thing, even as none root. If you put the nix file out of the tree, changes in dependencies can not be tracked correctly and you end up with editing the nix file.

Making the shell.nix development only is just plain wrong. Nix in most cases does the right thing between dev environment and building a derivation. If you don't allow building derivation you force people to not use their own mixxx build offline, which is just annoying. That the shell.nix is primary for development in tree, yes, but forcing one to, while creating a derivation is possible just makes no sense. It is very much possible that you won't be able to enter your dev shell without internet. Having fun on your gig with that...

I said multiple times that I would maintain this, I said that I will maintain custom CI runners for this if the resources are a problem. No CI will just cause it to break sooner or later, thats why I added them after the break. I don't mind if breaking them is allowed, I just want to get notice of it.

poelzi avatar Jan 18 '22 10:01 poelzi

I have nothing against removing the libc workarounds, I think they are obsolete now. But making this dev only is absolute nogo for me. Maybe we should switch to a flake.nix, that would make sense and simplify the dependencies a lot

poelzi avatar Jan 18 '22 10:01 poelzi

Nix is a isolated, self containing build system/package system that can run on any unix like system.

Sure, if you think that distro independence of the nix package is the key difference, we can also compare it with the flatpak build which is maintained externally, too: https://github.com/flathub/org.mixxx.Mixxx

If you put the nix file out of the tree, changes in dependencies can not be tracked correctly and you end up with editing the nix file.

This shouldn't be a big issue, Mixxx dependencies rarely change.

The point is that stuff in our tree kind of makes it "official", and we want to keep the list of officially supported distros small because we don't have the resources.

Holzhaus avatar Jan 18 '22 11:01 Holzhaus

Thank you for this PR, I am sorry that this topic is unexpected still controversy.

What are the pro and cons:

Contra:

  • This PR may puts extra maintenance work on us
  • It takes extra CI resources
  • A risk for frustration when remaining unmaintained, or is temporary broken

Pro:

  • The file already exists, this PR fixes it.
  • Lower the barrier for nix user by installing the dependencies
  • "Just" wraps the official CMake System
  • For now it IS Maintained.
  • A wiki page or external resource will fall out of sync more likely

Do I miss something? Is there a chance for a compromise?

Something like moving it to tools or add a disclaimer that this is not official?

daschuer avatar Jan 18 '22 12:01 daschuer

I second the suggestion of putting disclaimer somewhere making it clear that the nix support is maintained outside of the mixxx project. That could go in the README, and/or in the shell.nix file itself.

ywwg avatar Jan 19 '22 02:01 ywwg

This PR is marked as stale because it has been open 90 days with no activity.

github-actions[bot] avatar Apr 20 '22 00:04 github-actions[bot]