- cabal-devel - Haskell.org

Issue #2810: Search upwards for package directory
by Bardur Arantsson 05 Sep '15

05 Sep '15

Hey all, I've been working a bit on #2810 and would love to have initial review comments; see https://github.com/haskell/cabal/issues/2810 https://github.com/haskell/cabal/issues/2811 (pull req) (Btw, would it be possible to assign me to the issue?) I'd especially like comments on the following: - Does this look like a sane approach? - Are the any obvious-to-cabal-experts problems here? - I'd especially like feedback on the non-trivial FIXMEs. (There are some really obvious things I just haven't got round to.) Regards,

1 3

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

8 17

Pull request 2617 (don't require global package database)
by Michael Snoyman 17 Aug '15

17 Aug '15

A few months ago I noticed that pull request 2617[1] implements a change I'd love to see in Cabal: not requiring a global package database for GHCs that support this (7.6 and on). The change is small and self-contained, and looks like a good one to me, but it hasn't been merged. Any chance someone with a commit bit could review? [1] https://github.com/haskell/cabal/pull/2617

1 0

--only-depencies saves time?
by Peder Jakobsen 04 Aug '15

04 Aug '15

I’ve read the Simple Guide to Cabal at http://katychuang.com/cabal-guide/ <http://katychuang.com/cabal-guide/> It says: create a copy of a package by running the command cabal install Some flags can speed up this process --only-dependencies -jN to build N packages in parallel --dry-run to see what cabal plans to do (recommended) But here’s the thing (piping a word count from —dry-run) $ cabal install hakyll --dry-run | wc -l 97 cabal install hakyll --only-dependencies --dry-run | wc -l 96 So it takes 20+ minutes to install a package that you just want to check out for a few minutes, while your CPU melts down in the process? I must be missing something here…? Thanks again for your newbie support, greatly appreciated. P.J.

3 2

Newbie: Can't understand cabal errors during install of hakyll
by Peder Jakobsen 02 Aug '15

02 Aug '15

Hi, Been with Haskell just for few days, and thought it would be a good exercise to run a static site generator to get familiar with various tools, and I’m already running into “cabal hell” I think. :( $ cabal install hakyll Resolving dependencies... cabal: Could not resolve dependencies: trying: hakyll-4.7.2.0 (user goal) next goal: time (dependency of hakyll-4.7.2.0) rejecting: time-1.4.2/installed-d67... (conflict: hakyll => time>=1.5 && <1.6) trying: time-1.5.0.1 trying: process-1.2.0.0/installed-3a4... (dependency of hakyll-4.7.2.0) next goal: unix (dependency of process-1.2.0.0/installed-3a4...) rejecting: unix-2.7.0.1/installed-8ad... (conflict: time==1.5.0.1, unix => time==1.4.2/installed-d67...) rejecting: unix-2.7.1.0, 2.7.0.1, 2.7.0.0, 2.6.0.1, 2.6.0.0, 2.5.1.1, 2.5.1.0, 2.5.0.0, 2.4.2.0, 2.4.1.0, 2.4.0.2, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.0, 2.3.0.0, 2.2.0.0, 2.0 (conflict: process => unix==2.7.0.1/installed-8ad...) Backjump limit reached (change with --max-backjumps). I’m running OS X Yosemite 10.2.2 with all the latest versions of Haskell and cabal. Thanks you for listening. :) Peder

2 3

Re: Newbie: Can't understand cabal errors during install of hakyll
by Cyd Parser 01 Aug '15

01 Aug '15

Hi Peder, I'd recommend giving stack a try (https://github.com/commercialhaskell/stack) I have found it easier to use than cabal-install. Many executables will install just fine using `stack install <package-name>`. Packages that stack has trouble creating a build plan for (like hakyll) can usually be installed using the following: stack unpack hakyll cd hakyll-* stack init stack setup stack install `stack install` copies the resulting binaries to ~/.local/bin by default: add that to your path. Cheers, cydparser > Date: Sat, 1 Aug 2015 08:36:55 -0400 > From: Peder Jakobsen <pjakobsen(a)gmail.com> > To: cabal-devel(a)haskell.org > Subject: Newbie: Can't understand cabal errors during install of > hakyll > Message-ID: <D991FCF6-9271-49D9-AEB9-543F8A2F25CC(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > Been with Haskell just for few days, and thought it would be a good > exercise to run a static site generator to get familiar with various tools, > and I?m already running into ?cabal hell? I think. :( > > > $ cabal install hakyll > Resolving dependencies... > cabal: Could not resolve dependencies: > trying: hakyll-4.7.2.0 (user goal) > next goal: time (dependency of hakyll-4.7.2.0) > rejecting: time-1.4.2/installed-d67... (conflict: hakyll => time>=1.5 && > <1.6) > trying: time-1.5.0.1 > trying: process-1.2.0.0/installed-3a4... (dependency of hakyll-4.7.2.0) > next goal: unix (dependency of process-1.2.0.0/installed-3a4...) > rejecting: unix-2.7.0.1/installed-8ad... (conflict: time==1.5.0.1, unix => > time==1.4.2/installed-d67...) > rejecting: unix-2.7.1.0, 2.7.0.1, 2.7.0.0, 2.6.0.1, 2.6.0.0, 2.5.1.1, > 2.5.1.0, > 2.5.0.0, 2.4.2.0, 2.4.1.0, 2.4.0.2, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.0, > 2.3.0.0, 2.2.0.0, 2.0 (conflict: process => unix==2.7.0.1/installed-8ad.. > .) > Backjump limit reached (change with --max-backjumps). > > > I?m running OS X Yosemite 10.2.2 with all the latest versions of Haskell > and cabal. > > Thanks you for listening. :) > > Peder >

1 0

Uninstalling packages?
by Peder Jakobsen 01 Aug '15

01 Aug '15

Hi, just browsed through the user guide on managing packages at at https://www.haskell.org/cabal/users-guide/installing-packages.html <https://www.haskell.org/cabal/users-guide/installing-packages.html> Managing seems to imply that you should also be able to uninstall packages with a simple command. But there seem to be no instructions for how to do this for an installed packaged. What am I missing? Is it called “deregistering”? Thanks again, P.

2 2

Re: New release of GHC 7.8 to support OS X El Capitan
by Brandon Allbery 18 Jul '15

18 Jul '15

On Sat, Jul 18, 2015 at 7:39 AM, Ben Gamari <ben(a)well-typed.com> wrote: > I would like to understand the root-cause of the issue. It seems that > OS X will now raise EPERM instead of EACCES when certain files are > accessed. That being said, it's not at all clear to me which system call > is failing or why. Could someone familiar with El Capitan describe what > exactly is going on here? > The trace showed access("/usr/bin/ar", 2) => -1/EPERM (instead of -1/EACCES). http://apple.stackexchange.com/questions/193368/what-is-the-rootless-featur… appears relevant. Sounds to me like they automatically set a bunch of stuff immutable (chflags(1) schg flag; also see chflags(2), the underlying syscall) and bump the (equivalent of) securelevel so it can't be altered even by root after system boot. (Sadly, Apple did not bother to update the manpages to reflect launchd.) -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: New release of GHC 7.8 to support OS X El Capitan
by Ben Gamari 18 Jul '15

18 Jul '15

Oleg Grenrus <oleg.grenrus(a)iki.fi> writes: > Hi, > first some background: there is an issue with having Haskell on the > next OS X “El Capitan”: [1] caused by security updates in the > operating system. The cause is too old `unix` package, the same issue > as in [2] I would like to understand the root-cause of the issue. It seems that OS X will now raise EPERM instead of EACCES when certain files are accessed. That being said, it's not at all clear to me which system call is failing or why. Could someone familiar with El Capitan describe what exactly is going on here? > Could someone verify that my understanding of the issue is correct, > i.e. how Cabal-the-tool and Cabal-the-library interoperate. > > For me it seems, that one of the easiest ways to fix the issue (for > the users), is to have a new release in 7.8 branch, with updated > `unix` dependency. Or is it there too might hassle to be possible? I will bring this up in next week's GHC meeting. Cheers, - Ben

1 0

Request for feedback on spec/proposal for distributing package collections via hackage
by Duncan Coutts 14 Jul '15

14 Jul '15

Hi folks, I'd like to get feedback on a spec/proposal for distributing package collections via hackage. This is currently somewhere beyond vapourware but certainly not a fait accompli and hopefully it is at an appropriate point to get feedback. The basic idea is that package collections are: * useful (IMHO, one of the top two solutions to dependency hell, alongside nix-style package management); and * just as we distribute packages via hackage, we should also be able to easily distribute package collections. One would then use them with tools like cabal and stack. Distributing via hackage (both in the sense of the format/protocol and in the sense of the central community hackage instance) seems natural, and allows taking advantage of much of the infrastructure we have for packages already like: * existing user accounts and management infrastructure on the hackage website * allowing anyone to host collections on their own servers, just as they can host their own package archives currently (either as static file sets or with smart servers) * low barrier for distribution, potentially encouraging more collections to be created potentially covering more use cases * security infrastructure (currently in alpha) * automatic mirroring (currently in alpha) Two obvious examples are stackage-lts and stackage-nightly but if we lower the barrier for distribution then there may well be many more. For example, the existing Linux distros put a lot of effort into selecting and maintain package collections, and some of these collections could be distributed via hackage. In fast several Linux distributions already use Hackage's "distro" feature to advertise which versions of packages are provided by that distro. One can also imagine special-purpose collections, and there's probably cases we've not thought of yet. Package collections are different things from packages, not like "meta packages" that one gets in some package systems. A package collection at it's simplest is just a set of source package identifiers (ie names-version pairs). Like packages, package collections have names and versions and are immutable once distributed. The intention is that users can configure their tool to use collection(s), either by nailing down a specific collection version, or by not specifying a version it would default to the latest version of the named collection. (But the specific behaviour is up to the tool) Use cases: * versioned collections. For some collections the policy by which it's defined naturally uses meaningful versions. * daily collections. These can have a date-form version number imposed on them. * "live" "rolling" collections. These could have a simple monotonic increasing version with no particular meaning attached. For such collections, clients might be configured to use the latest (by not specifying a version), but it's always possible to pick a specific revision. * special-purpose collections. Not necessarily collections aiming to cover a large number of common packages, but aiming to cover some application area, or related stack of packages (e.g. some of the web frameworks). * negative collections. Collections of packages you may specifically want to avoid (e.g. deprecated by their authors, or known-broken). Using such collections would rely on clients that can be configured to treat it negatively. Specifics: A package collection specifies a set of source package ids (id being name-version pair). It also optionally specifies a (partial) flag assignment for any package name. The collection does not specify how tools should treat them. That is, a collection does not specify if it should be treated as a strong or a soft constraint, inclusive or exclusive, positive or negative. Such things are completely up to the client's policy and configuration. Similarly for flag assignments, collections do not specify whether tools should interpret these as strong or soft constraints. Syntax: Package collection names and versions exactly follow those of package names (but they live in a different namespace). For example, "stackage-lts-2.9", or "deprecated-343" (the latter being a "rolling" collection with a meaningless monotonically increasing version). A collection distributed in the archive format is just a text file with one entry per line, such as: foo-1.0 foo-1.1 bar >= 3 && < 4 bar +this -that So each line can be one of: * a simple package id * a package version range, using Cabal version range syntax * a package name with a flag assignment, + for on, - for off The interpretation of the above is that: * both foo-1.0 and foo-1.1 are in the collection (ie union not intersection) * all versions of bar between 3 and 4 are in the collection * the package bar has flag 'this' as True, and flag 'that' as False Of course for some collections the policy is that only one version of any package is included, but this is a policy question and the format itself does not impose this constraint. Hackage archive format: collection files live under a different prefix from package tarballs (but are still considered part of the archive) and are named after the collection id. The collection files are not compressed (but of course http clients and servers can negotiate transport compression). The collection files are not included in nor listed in the existing 00-index.tar.gz, but there's other json format metadata for a client to enumerate the available collections and versions. And like with package tarballs, a client that wants a specific collection version can construct the url and fetch it directly. Security: The hackage security system that's currently in alpha testing can easily be extended to cover collections, similarly to how it covers package tarballs. Misc notes: There is no requirement that a hackage-format repo containing collections be closed. That is, the collections may refer to packages not in that archive. This could be useful for private hackage repos that host a small number of private packages, but also host collections that refer both to the private packages and public ones from the community central hackage. The resolution of package names is done by the clients, and some clients may be configured to union/overlay multiple repos. On the other hand, for the central community hackage it may be sensible to enforce a policy that the collections it distributes be closed (ie refer only to packages distributed via hackage). Questions: Is this sufficiently flexible to fully cover the obvious use cases? Are there any interesting use cases that are excluded? Anything else? Duncan

3 4