[Nix-commits] [NixOS/nixpkgs] 171236: apple-sdk: Include system cups libraries

[Anthony Cowley]

  Branch: refs/heads/staging
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1712366bac9fabd51543545615b1ba3bccdc8776
  
https://github.com/NixOS/nixpkgs/commit/1712366bac9fabd51543545615b1ba3bccdc8776
  Author: Anthony Cowley <acow...@gmail.com>
  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)

[Anthony Cowley]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 29572c28a39b6c1aec15fccf324cbb6d75228988
  
https://github.com/NixOS/nixpkgs/commit/29572c28a39b6c1aec15fccf324cbb6d75228988
  Author: Anthony Cowley <acow...@gmail.com>
  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

[Anthony Cowley]

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

[Anthony Cowley]

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

[Anthony Cowley]

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] 

[Nix-commits] [NixOS/nixpkgs] 7b5641: tinyxml: darwin compatibility

[Anthony Cowley]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 7b56411fef87d7ab775640117bf461aaeb4a55e1
  
https://github.com/NixOS/nixpkgs/commit/7b56411fef87d7ab775640117bf461aaeb4a55e1
  Author: Anthony Cowley <acow...@gmail.com>
  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

Re: [Nix-dev] Fwd: Wiki is dead

[Anthony Cowley]

> On Feb 20, 2016, at 3:20 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru> 
> wrote:
> 
> Anthony Cowley <acow...@gmail.com> 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

[Anthony Cowley]

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 
>>> 

Re: [Nix-dev] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Anthony Cowley]

> 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?

[Anthony Cowley]

 On Feb 25, 2015, at 3:12 AM, Cody Goodman codygman.consult...@gmail.com 
 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 fuuze...@fuuzetsu.co.uk 
 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
  fuuze...@fuuzetsu.co.uk 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

Re: [Nix-dev] Will Haskell-ng and hackage2nix allow building *any* versions of deps?

[Anthony Cowley]

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
fuuze...@fuuzetsu.co.uk 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?

[Anthony Cowley]

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
fuuze...@fuuzetsu.co.uk 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