Comments (5)
It is true that the "re-generate in place" approach was extremely useful during development of the tool chain, but nowadays, it's less important simply because there are hardly any packages left that have non-standard patches:
$ hackage4nix -v pkgs/ 2>&1 | grep ^ignore | grep -v non-cabal
ignore non-hackage package pkgs/development/compilers/flapjax/default.nix
ignore known bad package pkgs/development/libraries/haskell/haskell-platform/2011.2.0.1.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2011.2.0.0.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2010.1.0.0.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2009.2.0.2.nix
ignore non-hackage package pkgs/development/libraries/haskell/haskell-platform/2010.2.0.0.nix
Of course, this doesn't mean that we won't have more packages that need patching in the future.
from cabal2nix.
After some more thought, I realize that I may have misunderstood what you meant. Do you suggest parsing flag assignments out of the existing Nix expressions instead of hard-coding them in cabal2nix?
from cabal2nix.
After some more thought, I realize that I may have misunderstood what you meant. Do you suggest parsing flag assignments out of the existing Nix expressions instead of hard-coding them in cabal2nix?
Exactly. I always thought we'd move to configuration files. But then
we'd have to store the config files. So why not use the existing
expressions as configuration? Perhaps it's a bad idea, and I'm not
fully convinced, but it's a suggestion as a basis for discussion.
from cabal2nix.
After more thought, I am still unable to make up my mind how I feel about this change.
If we'd parse flag assignments and extra configure parameters out of an existing expression -- rather than having a hard-coded list --, it means that cabal2nix won't know about these settings anymore. That's probably no big deal. In practice, I hardly ever run cabal2nix. I only use it to add new expressions, and those won't have any custom configuration defined anyway, so there is no loss of functionality.
The advantage of this approach would be that people can improve existing expressions (i.e. by adding flags) and commit their changes into the nixpkgs repository, rather than having to worry about the cabal2nix source code. That is a nice feature.
Of course, the parser would have to be pretty smart, especially if we ever get to the point where Cabal flags are supported in the generated expression in the way discussed in issue #6. In fact, if the functionality described in that issue would be available, then there wouldn't be a need to deal with Cabal flags at all in cabal2nix -- we could deal with that subject entirely in haskell-packages.nix, which feels like the superior approach.
I dunno ... I guess, I am undecided. :-|
from cabal2nix.
I guess it's probably safe to close this issue. It's been inactive for 3 years, and there's no immediate effort underway that touches this subject in any way.
from cabal2nix.
Related Issues (20)
- Map `extra-libraries: FLAC` to pkgs.flac HOT 4
- latest library doesn't pull in other latest library
- do not encourage use of `nix-env` HOT 1
- Confusing output when using --subpath in conjunction with a source that needs to be unpacked
- Improve tooling for making a new release
- Add --disable-library-profiling option HOT 2
- `posix_spawnp: illegal operation` HOT 1
- Support for GitHub/GitLab PR URLs HOT 1
- Add warning redirecting to nixpkgs manual at the top of every readthedocs page
- Get pkg-config dependencies from `pkg-configPackages` HOT 5
- Don't set mainProgram when it matches pname HOT 1
- Component-based build support for `cabal2nix` HOT 5
- Removing `configureCabalFlags` completely HOT 1
- Invalid Nix is generated for a .cabal file that has the `if` package as a dependency HOT 1
- Generate `meta.longDescription` HOT 2
- Generate version alias info to streamline updates HOT 3
- Support single-file Haskell script HOT 3
- Pulling from darcs zip file results in unpacking failure. HOT 1
- Status of the repository? HOT 2
- Adding pkgconfig-depends: hdf5 pulls in Haskell's hdf5, not system hdf5 HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cabal2nix.