DavHau

I was originally working on this PR because I wanted to use this bundler for https://github.com/davhau/nix-portable But eventually I ended up doing my own bundling from scratch. Anyways, I think...

According to multiple benchmarks online (like for example: https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/), bzip2 seems to be significantly slower to unpack than gzip and lzma. gzip would be the fastest but doesn't have good...

Seems like the wrong jdk was used. Now the gradle2nix tool runs successfully, but the build fails, complaining about all dependencies from `gradle-env.json` missing. So something must still go wrong...

Also when using `ExtrasProvider` as a Base class without any additional layer, one cannot call `ExtrasProvider.identify()` because it calls `identify()` on it's super class which is an abstract method and...

> Given the following flake > > ```nix > { > description = "A very basic flake"; > > inputs.flake-utils.url = github:numtide/flake-utils; > > outputs = { self, nixpkgs, flake-utils...

They way conda support is implemented, it uses the python interpreter from nixpkgs and therefore ignores python from conda. I'm not sure why pypy doesn't resolve in this case. But...

Just tested, and https://github.com/nix-community/dream2nix/pull/337 fixes this issue as well

> @DavHau Looks like the fix breaks the workarounds. This is a natural thing to happen if you keep your workarounds for yourself and never upstream them :P The more...

I think we should not silently ignore what the users specified. This might lead to unexpected behavior elsewhere. If we can tell for sure, that whatever the user wants will...

In the error message we could suggest to set ```nix { filter = project: project.relPath == "some/path"; project.translator = [cargo-toml]; } ``` This whole project settings API was a quick...