-
-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
gi-crystal: remove package #305484
gi-crystal: remove package #305484
Conversation
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
I think it may be better to add a
mkdir bin
cd lib/gi-crystal
shards build -Dpreview_mt --release --no-debug
cd ../..
cp lib/gi-crystal/bin/gi-crystal bin This may reduce some common codes. The only thing that needs to be patched is then removing |
I don't know whether |
These are good thoughts and I like it. But I think there's something wrong with the crystal on the Nix. While the "I use Arch btw" guys just do
mkdir bin
cd lib/gi-crystal
building shards -Dpreview_mt --release --no-debug
cd ../..
cp lib/gi-crystal/bin/gi-crystal bin because you still can't run I've spent so much time trying to package crystal applications because we have over-engineering for... over-engineering! While the Arch Linux guys have a human environment on their system, we create a declarative shards.nix file on top of the declarative shard.yml and shard.lock LOCK FILE. We have a lock file, why do we need another lock???? I feel like a gun without bullets. I have the dependencies, but I can't use them because gi-crystal can't run from /nix/store, and blake3.cr doesn't build because Crystal2nix doesn't run scripts after installation. While people use the default human-like environment, we can't use You know, it gets really crazy when we talk about reproducibility. We store deps into /nix/store, but we need the Because we don't like non-reproducible builds. But do we love so many hacks and patches? Do we really need all this over-engineering? It's not normal for you to need so much time just to run a program. Going back to the But I have to do so much work for this, so... I don't know, it would be great if we just run |
This situation with Crystal packages is actually the result of multiple factors, not just nix. The I am actually surprised that, when you packaged Having |
I think having gi-crystal in nixpkgs is a bad idea because this thing not backwards compatible. Means gi-crystal 0.23.0 may not work if the package expects gi-crystal 0.22.0. Another reason is that it is now a patched gi-crystal with changed logic. We have a problem: we need to support our patches, which Hugo won't support. If Hugo decides to generate bindings outside of the lib/ folder, we'll be fine with it. But we shouldn't apply these hard patches, our goal in my opinion is just to pack it. I don't want to add another flag to |
I think it should be fine to just do it in this PR. |
@ofborg eval |
@GrahamcOfBorg eval |
Why close? |
Cause lusasew made a cool update script for that package. I don't want to make another flag or builder for buildCrystalPackage func. But maybe someone wants to use gi-crystal as a nix package for development. So I decided to leave this package in nixpkgs. |
Description of changes
Remove
gi-crystal
package because it is useless now as we havecopyShardDeps
flag inbuildCrystalPackage
func, sogi-crystal
works now without any patches and packaging.Since both packages that depend on gi-crystal are broken, we can remove
gi-crystal
now.But it is better to wait until collision and rtfm are merged.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 馃憤 reaction to pull requests you find important.