[Nix-commits] [NixOS/nixpkgs] 171236: apple-sdk: Include system cups libraries
Branch: refs/heads/staging Home: https://github.com/NixOS/nixpkgs Commit: 1712366bac9fabd51543545615b1ba3bccdc8776 https://github.com/NixOS/nixpkgs/commit/1712366bac9fabd51543545615b1ba3bccdc8776 Author: Anthony Cowley Date: 2016-12-07 (Wed, 07 Dec 2016) Changed paths: M pkgs/os-specific/darwin/apple-sdk/default.nix Log Message: --- apple-sdk: Include system cups libraries The SDK includes cups header files, but not the libraries. The `nixpkgs.cups` definition doesn't build on darwin due to the SDK being too old. This change symlinks the system cups libraries into the old SDK. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 29572c: llvm-3.8: build shared library on darwin (#17671)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 29572c28a39b6c1aec15fccf324cbb6d75228988 https://github.com/NixOS/nixpkgs/commit/29572c28a39b6c1aec15fccf324cbb6d75228988 Author: Anthony Cowley Date: 2016-08-17 (Wed, 17 Aug 2016) Changed paths: M pkgs/development/compilers/llvm/3.8/llvm.nix Log Message: --- llvm-3.8: build shared library on darwin (#17671) - Enable the shared library build on darwin by default to match other platforms. - Fix the dylib file's name in the store - Symlink a versioned name as some tooling expects this. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > >> [What is] a concrete use case that works for you today but that > >> won't work after LTS-4 has been dropped? > > > > Someone who has a project that works with package versions in LTS-4, > > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to > > LTS-4 in their shell.nix for haskell packages. > > Oh, but you can absolutely do that! You can extend the set of available > packages to your heart's content and you can compose package sets that > provide any combination of versions as you please. The Haskell > infrastructure in Nix gives you that ability. > > > >>> You are removing that opportunity because it hasn't been used yet. > >> > >> I don't intend to remove any "opportunities" here. All I want to remove > >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs > >> repository. [...] > > > > If it's 850,000 lines of code, then that really seems like a Nix > > issue. If the point here is to declare bankruptcy and tell people to > > use stack which is able to refer to multiple versions of packages, > > then let's call it that. > > I have a hard time assigning meaning to vague terms like "removing > opportunities" and "declaring bankruptcy" in a technical conversation. I > am sorry, I just don't see how to these kind of things make a compelling > argument for distributing old LTS releases in Nixpkgs. I truly don't understand why this is hard for you to understand, so we are of a mind on this misunderstanding! There must be a language barrier or different understanding of what breaking version changes are between us. > > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need > > to make any changes to adopt LTS-6 until they are ready. I know that > > should a problem emerge with LTS-5, a project using stack has a good > > chance of benefiting from a new Stackage release. I know that after > > the changes you are making, the team using LTS-5 in nixpkgs will not > > have a working environment until they address any of the 5->6 > > breaking changes. > > This is true only if we assume that the team depending on LTS-5 updates > their copy of Nixpkgs to a version that breaks their code. But they > don't have to. They can use a version of Nixpkgs that works for them > until they're comfortable addressing the issues caused by an update. > Also, these changes I'll be making show up only in the branch we dub > "unstable". The release-16.03 branch, for example, has LTS-5 and will > continue to have it until all eternity. > > You realize that Nix allows you to override the contents of the Nixpkgs > version you're using without actually editing that version, right? You > can stick to any given version of Nixpkgs, but if an update of, say > libuuid, comes out that you'd like to have, then you can override only > that particular package in configuration.nix or ~/.nixpkgs/config.nix > without ever touching Nixpkgs itself. This gives you a stable package > plus selected, hand-picked updates. IMHO that is an awesome mechanism > for stable deployments. I think that telling users to stick to a single version of nixpkgs and take responsibility for cherry-picking individual security and bug fix commits to all Haskell and system libraries they depend on is the worst job a package management system can do while still calling itself a package manager. I do appreciate that you find such a setup appealing, so I'll say no more as this is solely your call. Anthony ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > > I draw a distinction between newer minor versions obsoleting old ones > > for purposes of bug fixes vs. for purposes of freezing packages. > > I am sorry, but I don't understand that distinction. In your original > response you suggested that dropping old LTS major releases like LTS-4 > from Nixpkgs would reduce your ability to use Nix, i.e. it would make > Nixpkgs less useful to you than it is today. I have a hard time seeing > how what might be the case, so I wonder whether you'd mind explaining to > me a concrete use case that works for you today but that won't work > after LTS-4 has been dropped? Someone who has a project that works with package versions in LTS-4, but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to LTS-4 in their shell.nix for haskell packages. > > The Stackage design is such that they *can* release bug fixes for > > older versions to help their users. > > Yes, I totally agree. Once Stackage starts releasing updates for older > LTS versions, it's a completely different situation and then carrying > around older LTS major releases would actually make sense. > > > > You are removing that opportunity because it hasn't been used yet. > > I don't intend to remove any "opportunities" here. All I want to remove > is some 850,000 lines of untested, unmaintained code from the Nixpkgs > repository. If there is a compelling use case for that code, then let's > talk about it! At the moment, however, the cost / benefit ratio of > keeping all those package sets around strikes me as bad, really, and I > don't think we should keep distributing that code unless there's a real > benefit to the effort. If it's 850,000 lines of code, then that really seems like a Nix issue. If the point here is to declare bankruptcy and tell people to use stack which is able to refer to multiple versions of packages, then let's call it that. > > As companies adopt Stackage package sets, they will have applications > > in production that they, A) really want bug fixes for; and B) do not > > want to keep on the hackage treadmill by following new releases. If a > > bug is found in an LTS-5 package within the next few months, a stink > > will be raised. > > I think everyone agrees that we *want* LTS-5 updates to come out even > after the release of LTS-6. Whether that is actually going to happen or > not, however, is speculation and neither you nor me can possibly know. I know that today a team using Nix can refer to LTS-5 in nixpkgs, and not need to make any changes to adopt LTS-6 until they are ready. I know that should a problem emerge with LTS-5, a project using stack has a good chance of benefiting from a new Stackage release. I know that after the changes you are making, the team using LTS-5 in nixpkgs will not have a working environment until they address any of the 5->6 breaking changes. > >> In Nix, we [freeze dependencies] by tagging a specific version of > >> Nixpkgs and sticking to that. Not only will that freeze the Haskell > >> dependencies, but it will also freeze all other dependencies, too. > > > > This is a big step backwards. You object that Stackage has not yet > > used their existing mechanism for releasing bug fixes for older > > Haskell libraries, and respond by promoting a mechanism that admits > > no bug fixes for any software at all. > > I have no idea what you are talking about. Nix offers a myriad of > different ways to cherry pick updates into a stable version of the > package set. Here's a quote that perhaps states it more clearly, "In Nix, we can solve these things by tagging a specific version of Nixpkgs and sticking to that. Not only will that freeze the Haskell dependencies, but it will also freeze all other dependencies, too." I saw on IRC that you use stack for some Haskell development and nixpkgs for other things, so I don't think there's much point in continuing this as it clarifies your intentions for the nixpkgs design. I have been using nix, and more recently nixpkgs, in place of stack, but if you are not then we simply have different goals and the issues I raise are not relevant. Anthony ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > > I know you didn't ask for feedback [...]. > > I'm always happy to get feedback! > > > If the top priority is receiving bug fixes, then keeping an LTS-4, > > LTS-5, LTS-6, etc. that tracks the most recent minor version makes > > sense. > > You seem to be saying that keeping an old major release like LTS-4 > around would somehow help us receive more bug fixes, but I can't see how > that would be true. According to git://github.com/fpco/lts-haskell.git, > the last time any LTS-4 update occurred was on 2016-01-18 -- almost half > a year ago. Surely, there have been point updates that fix bugs between > then and now, but LTS-4 does not seem to receive them, no? That is > because no-one maintains LTS-4. Stackage has moved on to LTS-5, or > rather: LTS-6 by now. > > So how exactly do we receive more bug fixes by distributing LTS-4? I meant that just tracking the latest minor version gets you everything possible regarding bug fixes. This was by way of agreement with your point that newer minor releases obsolete older ones. I go on to draw a distinction between newer minor versions obsoleting old ones for purposes of bug fixes vs. for purposes of freezing packages. > > > You say, "Stackage does not "maintain" any of its LTS releases," but > > the minor releases are precisely the offered maintenance. > > The thing is just that minor releases occur only for the latest major > release. LTS-6 has minor release at the moment, but LTS-5, LTS-4, etc. > do not! I agree that it would make sense to continue to distribute LTS-4 > if there were further minor releases to come out for that package set. > But there won't be any. As far as Stackage is concerned, LTS-4 is dead. The Stackage design is such that they *can* release bug fixes for older versions to help their users. You are removing that opportunity because it hasn't been used yet. Stackage is, relative to Haskell, very new. I think LTS-5 is far more widely used than previous major releases, and therefore stands a much greater chance of seeing a bugfix release even now, after the advent of LTS-6. The use of this safety feature is correlated to adoption: as companies adopt Stackage package sets, they will have applications in production that they, A) really want bug fixes for; and B) do not want to keep on the hackage treadmill by following new releases. If a bug is found in an LTS-5 package within the next few months, a stink will be raised. > > Furthermore, there is no reason a new LTS-5 release can not be issued > > after the first release of LTS-6. > > Sure, this *could* happen and it would be great! Then we'd have a real > long-term supported package set that would be worth-while to distribute. > > > > The cultural prominence of Stackage means that the need for security > > fixes to older versions can actually be promulgated because Stackage > > has users. > > I am sorry, but I have no idea what that sentence means. It means that problems get publicity. When there are notable changes to package versions in Stackage (e.g. with aeson), there is a reddit discussion, posts on twitter, and chatter on IRC. This is the kind of herd immunity that Stackage provides: if one person finds a problem with a version of a library included in a Stackage package set, they can raise an alarm that is easy for everyone to interpret and address. Pre-Stackage, this rarely if ever happened because every application in production was running against a unique collection of versions that the cabal solver picked on an arbitrary day. > > > For a modest application, specifying a particular Stackage release is > > a concise way of freezing Haskell dependencies. > > In Nix, we can solve these things by tagging a specific version of > Nixpkgs and sticking to that. Not only will that freeze the Haskell > dependencies, but it will also freeze all other dependencies, too. This is a big step backwards. You object that Stackage has not yet used their existing mechanism for releasing bug fixes for older Haskell libraries, and respond by promoting a mechanism that admits no bug fixes for any software at all. > > > A typical Stackage definition is about 70KB. > > Huh? That's not what I am seeing in git://github.com/fpco/lts-haskell.git: > >$ ls -lh lts-6.2.yaml >-rw-r--r-- 1 simons users 4.7M Jun 6 11:58 lts-6.2.yaml Your data here is quite disingenuous: that file contains lists of github users, six hashes per package, a kind of reverse dependency information (users), and I do not know what else to aid with Stackage maintenance. If you are a Haskell programmer and wish to use Stackage versions, you do this, $ curl https://www.stackage.org/lts-6.2/cabal.config > cabal.config $ ls -lh cabal.config -rw-r--r-- 1 acowley staff69K Jun 8 20:22 cabal.config Those are the versions of packages on hackage that constitute a Stackage release. nixpkgs will need additional data to address your point about offi
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Fellow Haskell Hackers, > > once the LTS 7.x package set comes out, I intend to make the following > changes in "master": > > - All haskell.packages.lts.* package sets will disappear. > > - haskellPackages will loosely follow the most recent LTS release, > > where "loosely" means that we'll honor the mandated version bounds for > libraries but tend to ignore them for executables. > > Nixpkgs has shipped every single LTS Haskell version ever released as > well as an up-to-date copy of the Stackage Nightly package set for the > last 9 months or so, and during that time we've gained insights that > suggest this practice is an ineffective use of our resources [1]. > > 1. It's pointless to distribute LTS Haskell version x after the release > of version x+1. > > Stackage does not "maintain" any of its LTS releases. Rather, the > Stackage volunteers compile a list of package versions, test and verify > them to the best of their abilities, release that list, and then they > never touch it again. For example, there won't be any update to LTS > Haskell 5.4. That update comes in the form of a new package set called > LTS 5.5. So if LTS 5.4 happens to recommend a package that has a serious > problem, then that problem will remain there forever. So what is the > point of distributing LTS 5.4 after the release of 5.5? Apparently, > Stackage intends LTS 5.5 to *replace* the previous version, so isn't > that what we should do, too? > > Furthermore, a major release like LTS Haskell 5.x receives no updates > either after LTS 6.x has comes out, so by the same logic there is no > point in distributing LTS 5.x after LTS 6.x has become available. > Contrary to what the name suggests, LTS versions have no guaranteed > lifetime or support cycle. Stackage does not offer any "long-term > support" in the sense distributions use the word. "Releases" are merely > names for tested snapshots of a project that essentially follows a > rolling release model. > > 2. Following LTS strictly may deprive us of important security updates. > > Whether a package update goes into a minor LTS release or not depends on > whether that update increments the first or second segment of its > version number. 6.1.1 -> 6.1.2 will make it, but 6.1.1 -> 6.2 won't. > That is a pretty good rule based on the assumption that all LTS > contributors follow it, which -- as you will have guessed -- is not the > case. The tool git-annex, for example, uses version numbers that have > only two levels: .. Due to that scheme, git-annex updates > aren't considered for minor LTS releases, which means that security > relevant fixes don't reach LTS users until the next major LTS release > [2]. > > 3. Stackage Nightly is not a stable package set. > > Our main package set, haskellPackages, corresponds to Stackage Nightly. > We made that choice assuming that it would guarantee us a good mixture > of a stable user experience on one hand and an up-to-date packages on > the other. Recent experience has shown, however, that Stackage Nightly > *will* break some of its packages knowingly on the occasion: the Nightly > package set recently moved to GHC 8.0.1, but a handful of libraries and > applications blocked that (desirable) update. At that point one would > expect people to postpone the compiler update, but what happened instead > is that the troublemakers were simply removed from Stackage [3]. > > Now, that is a perfectly legitimate decision to make, it just had the > unfortunate side effect of breaking all those builds for users of > Nixpkgs in the process, so arguably following Stackage Nightly with our > main package set might be a bad idea. > > 4. Stackage does not provide a stable users experience for Nixpkgs. > > Stackage releases come out only after a complete test build of all > packages has succeeded. Unfortunately, those tests don't always catch > all issues we might run into, because we compile packages in a different > environment. Stackage builds on Travis-CI using 64-bit Ubuntu Linux with > static linking. Our builds run on all kinds of Linuxes and on Darwin, we > support 32 bit platforms, and we link everything with shared libraries > by default. This means that some of our builds fail even though they > succeed in Stackage [4]. Now, we usually report these issues to Stackage > and on some occasions they've made an effort to fix the issue, but on > other occasions their response was, essentially, "works for me". That > leaves us in an odd place, because we're nominally following Stackage > (and our users rely on getting exactly those builds that Stackage > promises), but at the same time we have no choice but to deviate from > Stackage because the builds they want us to do just don't work. > > As such, it's a good idea to use Stackage as a *recommendation* for our > package set, but we cannot expect to be 100% compliant to Stackage and > provide a stable user experience at the same time. > > Best regards, > Peter > > > [1] https://github.
[Nix-commits] [NixOS/nixpkgs] 7b5641: tinyxml: darwin compatibility
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 7b56411fef87d7ab775640117bf461aaeb4a55e1 https://github.com/NixOS/nixpkgs/commit/7b56411fef87d7ab775640117bf461aaeb4a55e1 Author: Anthony Cowley Date: 2016-05-21 (Sat, 21 May 2016) Changed paths: A pkgs/development/libraries/tinyxml/2.6.2-cxx.patch M pkgs/development/libraries/tinyxml/2.6.2.nix Log Message: --- tinyxml: darwin compatibility - Relax the baked-in assumption that g++ is used to build and link - Use the appropriate shared library extension on darwin ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] e4e422: pcl: visualization components in darwin
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: e4e422aa91b76e2f5bcdeef107cf03dc94a9ebc5 https://github.com/NixOS/nixpkgs/commit/e4e422aa91b76e2f5bcdeef107cf03dc94a9ebc5 Author: Anthony Cowley Date: 2016-05-21 (Sat, 21 May 2016) Changed paths: M pkgs/development/libraries/pcl/default.nix M pkgs/top-level/all-packages.nix Log Message: --- pcl: visualization components in darwin Supplies the necessary frameworks and build system tweaks to build the vtkWithQt4 components on darwin. This follows on from PRs #14705 and #14749. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Fwd: Wiki is dead
> On Feb 20, 2016, at 3:20 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru> > wrote: > > Anthony Cowley writes: >> Bringing together what Thomas and Freddy say here, it seems to me that >> a rather ideal mixture would be something unstructured like a wiki >> with buttons for readers saying, "This helped me" or "This did not >> work". >> >> The point being that once a wiki item gets a handful of positive >> votes, it gets turned into an Issue on the manual for someone with a >> better understanding of how things are put together to find it a home. > > Anthony, this is an excellent idea that you have came up to! > > The question that immediately comes my mind is -- what "this" would mean? > > A section? A paragraph? Something even more structured? > > ..and then there is this perpetually simple matter of programming > to make it happen.. > > -- > с уважениeм / respectfully, > Косырев Сергей I was imagining feedback attached to section headings. They could perhaps be buttons inserted with CSS/JS or something tied more into the wiki engine. The links could ping a counter running as a separate web service with what page/section they are associated with. I think the feedback mechanism should be as simple as a Reddit upvote since any impact it has will be mediated by an expert reviewer who will use their judgment to determine what valuable nuggets should be promoted to the manual. Anthony ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fwd: Wiki is dead
Bringing together what Thomas and Freddy say here, it seems to me that a rather ideal mixture would be something unstructured like a wiki with buttons for readers saying, "This helped me" or "This did not work". The point being that once a wiki item gets a handful of positive votes, it gets turned into an Issue on the manual for someone with a better understanding of how things are put together to find it a home. At that point, the wiki item could have a link to the manual added. Similarly, things marked obsolete could at some point get a review from an expert who could make the obsolescence official so that the item gets a big red banner warning future readers. The expert reviewer could zero out the counts if the votes are due to misunderstandings. The votes are not for publicity, but for triage. This does not address spam, but offloading authentication to someone like github could still be used. What this does is free would-be doc or recipe contributors from being paralyzed by unfamiliarity with language style or naming conventions, while still establishing a path for their contributions to make it into the manual. Anthony > On Feb 20, 2016, at 8:54 AM, Freddy Rietdijk wrote: > > Adding documentation is one thing, maintaining it is a second. It's great if > someone is willing to convert contributions to Docbook, and I'm thankful for > that. However, that does not help much if you want to modify parts of it. And > as Nixpkgs is updated, so should the documentation. > > I agree writing docs isn't peoples favorite activity, but somehow, when I see > the amount of content that's on the Wiki, I do wonder: how come people chose > to put it there instead of in the manual? Was it because there never really > was a manual where the contents would fit in? Or was it because it was more > convenient to contribute to the wiki instead of the manual? > I haven't been around long enough with this project, so I don't know. Some of > you will have a better idea. > > Being able to convert to Docbook like is done with the Haskell guide makes it > easier for others to contribute, at least, if you know how that conversion is > done. > > Some time ago I began using Nix because I like it. Python packaging is a mess > as Domen explained during NixCon, but with Nix it works much better. I've > contributed Python packages, and now I would like to share how it is done. As > acoustician/researcher my work activities are quite different from I bet most > other Nix users. Learning Nix was a big investment, but is I think worth it. > Learning Docbook on the other hand... > > If you want to scare away contributors by keeping the barrier high, then keep > the documentation the way it is. > > > >> On Sat, Feb 20, 2016 at 2:04 PM, Thomas Hunger wrote: >> I'm tool agnostic but +1 on having a cookbook in git for the review-workflow >> (avoids wiki spam). I have a number of snippets (how to remove gc roots, >> haskell profiling, how to use ihaskell properly, many more) but no good >> place to put them. >> >> I've started a git-book thing [1] a while back to collect these but didn't >> get very far. I'd much rather contribute to a common, low-barrier-to-entry >> repository than rolling my own. >> >> In my experience just providing the structure will eventually attract >> content because adding a small snippet is the path of least resistance for >> each individual contributor. Maybe we could add a banner "This is how you >> add a snippet" and buttons "File a bug that this is wrong / outdated" to >> each snippet? >> >> Rok - I know it's not free software but maybe it's worth setting up a google >> docs spreadsheet for coordinating the migration once we've settled on a >> tool? I will contribute. >> >> ~ >> >> [1] >> https://github.com/WeAreWizards/nixbyexample >> >>> On 20 February 2016 at 12:06, Freddy Rietdijk >>> wrote: >>> I agree with Vladimir that we already have the infrastructure, the Nixpkgs >>> repository. >>> >>> What is needed is a clearer way where to put certain documentation and a >>> lower barrier for contributing. In `Redesign of documentation` I came with >>> a proposal of how to structure the documentation. A wiki has a low barrier >>> for contributing, however, it also has many disadvantages, which you would >>> not have if we use, say, the Nixpkgs repository. >>> >>> A big barrier, in my opinion and I'm pretty sure also in that of others, is >>> the current format of the Nixpkgs manual. I can understand why docbook is >>> used, and I think it should be used for say the Nix manual, but for a >>> User's Guide to which many of us would/should contribute, the barrier is >>> just too high. >>> >>> On the branch https://github.com/FRidh/nixpkgs/tree/usersguide I >>> implemented the proposed redesign. >>> The documentation is split into two documents, the User's Guide, and the >>> Contributor's Guide. The User's Guide is divided into three parts: >>> Intro
Re: [Nix-dev] Feature request: replace the Darwin stdenv with the pure Darwin stdenv
> On Oct 2, 2015, at 10:26 AM, Daniel Peebles wrote: > > If nobody objects, I think we should just switch over. The only people > interested in maintaining the darwin ecosystem on Nix don't really want to > have to maintain two parallel stdenvs, and unless someone stands up to fight > for the old impure stdenv, I think everyone will be long-term better off with > the pure one. Yes, there will be some short- and medium-term pain during the > switch, but there already is with the El Capitan upgrade. I vote to go ahead with this, too. Getting just a little help from hydra in terms of binaries will make it a lot easier to contribute to pure-Darwin. Anthony > >> On Fri, Oct 2, 2015 at 3:01 AM, Michael Sperber >> wrote: >> >> Daniel Peebles writes: >> >> > Probably obvious, but I'm in favor of switching/merging :) >> >> +1 >> >> -- >> Regards, >> Mike >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
> On Feb 25, 2015, at 3:12 AM, Cody Goodman > wrote: > > Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes > were transparent. > This is correct. Linking into the local sandbox is a separate, optional step. I wanted this as it let me continue using my old pre-nix workflow. However, fully supporting a workflow based entirely on nix-shell is not yet done as I was content to let cabal pass GHC all the necessary inputs based on sandbox contents. The missing piece for a nix-shell workflow is to duplicate that command line generation logic. What cabbage buys you is that you're starting with derivations whose dependencies are pinned to specific versions and flag settings. This lets you drop multiple instances of the same version of a package in your store for re-use in subsequent builds (this is all spelled out in more detail in the cabbage documentation). For nix-shell, you could save off an environment variable that just lists off the compiled libraries in the store for every derivation in the .cabbages directory. This would amount to a tweak of the existing generation of commands that link those libraries into the local sandbox. Anthony >> On Feb 24, 2015 11:57 PM, "Mateusz Kowalczyk" >> wrote: >> On 02/25/2015 03:01 AM, Anthony Cowley wrote: >> > This almost certainly isn't ready for release, but I'd like to avoid >> > duplicating efforts if other people want to work on it... >> > >> > Here is cabbage https://github.com/acowley/cabbage >> > >> > It is a tool for doing the obvious thing: use the cabal solver to find >> > a build plan, then build the specific version of each package, and >> > then link them into the sandbox in the current directory. >> > >> > As I said, this script has every warning tape and flashing light >> > imaginable attached to it. I've used it to install ghc-mod, pandoc, >> > hakyll, a bunch of web things like amazonka, and my Frames package >> > with all its demos (involving Chart, diagrams, JuicyPixels, and who >> > knows what else). >> > >> > There are missing pieces outlined in the Tasks list at the end of the >> > Org file that is the source code for the script. I would more than >> > welcome contributions as this is how I would like to use Nix with >> > Cabal, and getting help from like-minded folks would be a big boost! >> > >> > Anthony >> >> While interesting, I feel it is doing too much and using the wrong >> tooling at least for me. I have the power of nix-shell, I don't want to >> be using ‘cabal sandbox’ on top of it, that very much goes against all >> the benefits of using nix-shell to begin with. I don't call ‘cabal’ >> manually pretty much ever unless it's ‘cabal update’ though I know of >> cases where you still might prefer cabal repl over ghci, something I >> hopefully won't have to deal with. >> >> I think a simpler solution from the user experience perspective is if we >> can do something like ‘hackage2nix myproject.cabal’ which runs through >> the cabal solver and then spits out hackage-packages.nix with only the >> stuff that is needed with versions that are needed. We can now happily >> use this package set in our shell.nix or whatever just like we do today >> with manually written package sets. If it can do that then everything >> else works just like it does today already which is a good thing ;). If >> I want to do this today then I nix-build a package, see what version in >> complains about, add the package to the project's set and repeat until >> physically ill. >> >> > >> > On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk >> > wrote: >> >> On 02/22/2015 12:04 PM, Peter Simons wrote: >> >>> Hi Cody, >> >>> >> >>> > haskellngPackages doesn't seem to have all versions of all >> >>> dependencies... >> >>> >> >>> I'm not sure what you mean by "all versions of all dependencies". >> >>> Dependencies >> >>> of what exactly? The way I understand the term, "dependency" has meaning >> >>> only >> >>> as a relationship between two packages, i.e. "transformers" is a >> >>> dependency of >> >>> "mtl". I'm not sure how to apply that interpretation to your question? >> >>> >> >>> If you're asking why hackage-packages.nix doesn't contain every single >> >>> version >> >>
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
This almost certainly isn't ready for release, but I'd like to avoid duplicating efforts if other people want to work on it... Here is cabbage https://github.com/acowley/cabbage It is a tool for doing the obvious thing: use the cabal solver to find a build plan, then build the specific version of each package, and then link them into the sandbox in the current directory. As I said, this script has every warning tape and flashing light imaginable attached to it. I've used it to install ghc-mod, pandoc, hakyll, a bunch of web things like amazonka, and my Frames package with all its demos (involving Chart, diagrams, JuicyPixels, and who knows what else). There are missing pieces outlined in the Tasks list at the end of the Org file that is the source code for the script. I would more than welcome contributions as this is how I would like to use Nix with Cabal, and getting help from like-minded folks would be a big boost! Anthony On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk wrote: > On 02/22/2015 12:04 PM, Peter Simons wrote: >> Hi Cody, >> >> > haskellngPackages doesn't seem to have all versions of all dependencies... >> >> I'm not sure what you mean by "all versions of all dependencies". >> Dependencies >> of what exactly? The way I understand the term, "dependency" has meaning only >> as a relationship between two packages, i.e. "transformers" is a dependency >> of >> "mtl". I'm not sure how to apply that interpretation to your question? >> >> If you're asking why hackage-packages.nix doesn't contain every single >> version >> of every package registered on Hackage, then the answer is because that would >> be a database containing well over 50,000 packages, the vast majority of >> which >> no-one will ever care about (nor will they ever compile). So it seems >> pointless >> to distribute all that stuff as part of Nixpkgs. >> >> Best regards, >> Peter >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > A related question: is there a way to generate a package list containing > exactly the versions of dependencies we require? > > Say we have a package with cabal file > > A == 1.0 > B > 2.0 > C < 0.5 > > but the latest Hackage has versions lower and higher &c and that's what > is in nixpkgs. I found myself wishing that there was an easy to just say > ‘give me a set of packages that's valid from cabal's point of view’ > rather than what we currently tend to do which is ‘include latest > versions of everything, jailbreak and hope it works’ which is fine for > nixpkgs but subpar if we just want that one project working but it > requires specific versions of dependencies. > > -- > Mateusz K. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?
This almost certainly isn't ready for release, but I'd like to avoid duplicating efforts if other people want to work on it... Here is cabbage https://github.com/acowley/cabbage It is a tool for doing the obvious thing: use the cabal solver to find a build plan, then build the specific version of each package, and then link them into the sandbox in the current directory. As I said, this script has every warning tape and flashing light imaginable attached to it. I've used it to install ghc-mod, pandoc, hakyll, a bunch of web things like amazonka, and my Frames package with all its demos (involving Chart, diagrams, JuicyPixels, and who knows what else). There are missing pieces outlined in the Tasks list at the end of the Org file that is the source code for the script. I would more than welcome contributions as this is how I would like to use Nix with Cabal, and getting help from like-minded folks would be a big boost! Anthony On Tue, Feb 24, 2015 at 5:38 PM, Mateusz Kowalczyk wrote: > On 02/22/2015 12:04 PM, Peter Simons wrote: >> Hi Cody, >> >> > haskellngPackages doesn't seem to have all versions of all dependencies... >> >> I'm not sure what you mean by "all versions of all dependencies". >> Dependencies >> of what exactly? The way I understand the term, "dependency" has meaning only >> as a relationship between two packages, i.e. "transformers" is a dependency >> of >> "mtl". I'm not sure how to apply that interpretation to your question? >> >> If you're asking why hackage-packages.nix doesn't contain every single >> version >> of every package registered on Hackage, then the answer is because that would >> be a database containing well over 50,000 packages, the vast majority of >> which >> no-one will ever care about (nor will they ever compile). So it seems >> pointless >> to distribute all that stuff as part of Nixpkgs. >> >> Best regards, >> Peter >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > A related question: is there a way to generate a package list containing > exactly the versions of dependencies we require? > > Say we have a package with cabal file > > A == 1.0 > B > 2.0 > C < 0.5 > > but the latest Hackage has versions lower and higher &c and that's what > is in nixpkgs. I found myself wishing that there was an easy to just say > ‘give me a set of packages that's valid from cabal's point of view’ > rather than what we currently tend to do which is ‘include latest > versions of everything, jailbreak and hope it works’ which is fine for > nixpkgs but subpar if we just want that one project working but it > requires specific versions of dependencies. > > -- > Mateusz K. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
