Re: hackage reverse dependencies
It seems to me that all we really need is a list of all first generation revdeps on a given package (any version), each specified maybe as (in pseudodata): type VersionRange = (Version,Version) type RevDep = (PackageName,[VersionRange]) RevDeps = [RevDep] (alt M.Map PackageName [VersionRange]) RevDepStructure = M.Map PackageName RevDeps I can see how things get uglier if we instead do: RevDepStructure = M.Map PackageName (M.Map Version RevDeps) but I think the latter structure is potentially too granular for most uses? --Gershom On Mon, Oct 14, 2013 at 2:44 PM, Duncan Coutts wrote: > On Mon, 2013-10-14 at 12:18 -0400, Carter Schonwald wrote: >> So you're saying we need to add a db proper to hackage2 server, like SQLite >> or Postgres so as to make it more performant for interesting features? >> What's needed to do that? > > I don't think that's needed at all. > > What we need is to look carefully at what we want from a revdeps feature > and then look carefully at what info should be stored (ie cached) and > what should be calculated on demand. > > It just needs someone to spend some time on the feature, there's no need > to panic about the data storage (especially before looking at what is > actually needed). > > Duncan > >> On Monday, October 14, 2013, Matthew Gruen wrote: >> >> > Hey, thanks for taking an interest in this. There is kind of a >> > space-time-featureset tradeoff with revdeps, unfortunately. It seems to me >> > like the challenge doesn't come so much from indirect deps, but rather from >> > the sheer number of versions there are! There are 5600+ packages and 33800+ >> > versions, and the set of dependencies of foo-1.2 vs foo-1.3 can be >> > completely different. Not to mention, when you look at the package page for >> > a particular version, you may want to see the revdeps *for that version*, >> > and at this point there are a billion possible combinations. npm's UI, in >> > contrast, has an "always in HEAD" kind of feel. >> > >> > If you are interested in how the disabled implementation worked, by the >> > way, I have a post here (as gracenotes): >> > https://github.com/haskell/hackage-server/issues/40 >> > >> > So revdeps is great, and there are many different killer uses for it, such >> > as popularity metrics and finding upper version bounds which need updating. >> > In sum, these require keeping around a lot of data. Because there's so >> > much, acid-state is probably not a good place to store it. Not to mention, >> > it's time-consuming to generate it from scratch and space-consuming to keep >> > around data structures to incrementally update it. So there are some tool >> > limitations, but it seems fundamentally tricky to do frugally. >> > >> > Matt >> > >> > >> > >> > On Mon, Oct 14, 2013 at 12:20 AM, Jens Petersen < >> > j...@community.haskell.org> wrote: >> > >> >> Not really complaining :) but one of the things I had been looking >> >> forward to with Hackage2 was the display of reverse-dependencies, but I >> >> gather it was disabled for now (because it loads the server too much when >> >> updating the data iirc?). >> >> >> >> I was thinking perhaps a compromise would be to show only direct >> >> reverse-dependencies rather than including all indirect dependencies too. >> >> Perhaps that would make it scale better? I think direct dependency >> >> information is the most useful anyway (and also what packdeps provides). >> >> >> >> Before doing anything I thought I would ask here first if this makes >> >> sense and should be work? >> >> I for one would still really like to see basic reverse dependencies info >> >> listed on hackage (I noticed yesterday that npm has them too). >> >> >> >> Jens >> >> >> >> ___ >> >> cabal-devel mailing list >> >> cabal-devel@haskell.org >> >> http://www.haskell.org/mailman/listinfo/cabal-devel >> >> >> >> >> > >> ___ >> cabal-devel mailing list >> cabal-devel@haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel > > > -- > Duncan Coutts, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [patch] lincenses warning
Thanks for this patch! I've kicked off a discussion with hackage administrators and the haskell committee about the general approach we want to take to the license situation on hackage, and how to properly document our policies. It seems to me that merging this makes sense regardless, but I don't know what others may think? Cheers, Gershom On Tue, Mar 3, 2015 at 9:58 AM, Francesco Ariis wrote: > Dear Cabal developers, > spurred by this discussion on haskell-cafe [1], I attach a small patch > on licence warnings. It: > > - reverts AllRightsReserved as PackageDistInexcusable, as it was > before this commit [2]. > Reading the comments in Check.hs, this datatype is for issues which > "[are] OK in the author's environment but [are] almost certain to be > a portability problems for other environments", which I think it is > the case. > > - adds a PackageDistSuspicious warning on OtherLicense. The text of > the warning encourages the developer to choose from licences > suggested by the OSI or FSF, if they don't want to use a licence > recognised by cabal. > > Thanks > -Francesco > > > [1] > http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html > [2] > https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9 > > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: [patch] lincenses warning
Well on “other license” it should just warn that it _should be_ an open source license to be uploaded to hackage. That seems fine to me — its an informational message. Also note that we don’t accept packages with no license, just as we don’t accept AllRights licenses. So yes, the “no license” fact is true, but irrelevant. —g On March 7, 2015 at 12:50:39 AM, Carter Schonwald (carter.schonw...@gmail.com) wrote: > i'm very uncomfortable with the "warn on other-license" change. I think > theres lots of valid reasons that someone may be using an amended license > (eg BSD / MIT plus an explicit patent license grant) that strictly more > open/free than any standard OSS license on the planet. > > Edward Kmett raise the valid point on IRC that by current international > treaties, authors no longer need to mark their works "All rights reserved" > to protect their copy right, but rather that if no other license is > specified, ANY work is by definition all rights reserved! > > anyways, thats my 2cents for the evening > > cheers-Carter > > On Tue, Mar 3, 2015 at 1:56 PM, Gershom B wrote: > > > Thanks for this patch! > > > > I've kicked off a discussion with hackage administrators and the haskell > > committee about the general approach we want to take to the license > > situation on hackage, and how to properly document our policies. It seems > > to me that merging this makes sense regardless, but I don't know what > > others may think? > > > > Cheers, > > Gershom > > > > > > On Tue, Mar 3, 2015 at 9:58 AM, Francesco Ariis wrote: > > > >> Dear Cabal developers, > >> spurred by this discussion on haskell-cafe [1], I attach a small patch > >> on licence warnings. It: > >> > >> - reverts AllRightsReserved as PackageDistInexcusable, as it was > >> before this commit [2]. > >> Reading the comments in Check.hs, this datatype is for issues which > >> "[are] OK in the author's environment but [are] almost certain to be > >> a portability problems for other environments", which I think it is > >> the case. > >> > >> - adds a PackageDistSuspicious warning on OtherLicense. The text of > >> the warning encourages the developer to choose from licences > >> suggested by the OSI or FSF, if they don't want to use a licence > >> recognised by cabal. > >> > >> Thanks > >> -Francesco > >> > >> > >> [1] > >> http://mail.haskell.org/pipermail/haskell-cafe/2015-February/118411.html > >> [2] > >> https://github.com/haskell/cabal/commit/8d449ba3231445726272eac4dcf7b2b4a5508db9 > >> > >> > >> ___ > >> cabal-devel mailing list > >> cabal-devel@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > >> > >> > > > > ___ > > cabal-devel mailing list > > cabal-devel@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal webpage on haskell.org
Mitek: Go ahead and send on a public ssh key to admin@ and we'll get you access to that portion of the site. In terms of further contributions / places to start, Johan mentioned he would in particular appreciate help in automating this process: https://github.com/haskell/cabal/wiki/Making-a-release Sound good? Cheers, Gershom On Sun, Mar 15, 2015 at 3:18 AM, Miëtek Bak wrote: > There are at two problems with the Cabal webpage on haskell.org: > > > 1. The release directories are no longer browseable, as attempting to list > their contents fails with 403 errors. > > Being able to browse these directories was probably the only way to locate > binary downloads for releases older than the one linked from the download > page, which is currently 1.22.0.0. > > https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/ > https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/ > https://www.haskell.org/cabal/release/ > > > 2. 1.22.0.0 is still listed as the latest version on the download page, even > though 1.22.1.0 and 1.22.1.1 were released 3 weeks ago. > > https://www.haskell.org/cabal/download.html > https://github.com/haskell/cabal/releases > > > How can I help get this fixed? > > > -- > Miëtek > > > > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal webpage on haskell.org
I’ve re-enabled the directory listings for https://www.haskell.org/cabal/release/ (admins, note: I just changed the nginx.conf directly, we need to backport all our changes into the full deploy scripts…) —Gershom On March 15, 2015 at 3:18:52 AM, Miëtek Bak (mie...@bak.io) wrote: > There are at two problems with the Cabal webpage on haskell.org: > > > 1. The release directories are no longer browseable, as attempting to list > their contents > fails with 403 errors. > > Being able to browse these directories was probably the only way to locate > binary downloads > for releases older than the one linked from the download page, which is > currently 1.22.0.0. > > https://www.haskell.org/cabal/release/cabal-install-1.22.0.0/ > https://www.haskell.org/cabal/release/cabal-install-1.20.0.3/ > https://www.haskell.org/cabal/release/ > > > 2. 1.22.0.0 is still listed as the latest version on the download page, even > though 1.22.1.0 > and 1.22.1.1 were released 3 weeks ago. > > https://www.haskell.org/cabal/download.html > https://github.com/haskell/cabal/releases > > > How can I help get this fixed? > > > -- > Miëtek > > > > > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal and simultaneous installations of the same package
On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones wrote: > > | 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. My understanding is that the problem Yitz is discussing is much more straightforward and easy to fix. The issue is that if I have an "empty" global package db and enter a sandbox and cabal-install something, then I will get one package install plan. But if I have a "well populated" package db, then attempt to cabal-install something in the sandbox, the plan will attempt to use the packages from that global db, and so will often be a different, and perhaps worse plan (especially if it runs into quirks in the solver). This is discussed on the associated reddit thread here: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7 As I proposed on the main email thread, I think it would make sense to make the easy, default option the one which, in sandboxes, effectively ignores the global db for solving. This leads to more duplication and longer build times, but it is safer. However, we should have an easy setting/flag (to be set when initializing a sandbox or any time thereafter) which can switch the preference over to preferring to use already installed versions in the global db. That way, new users can, naively, get a _lot_ of isolation with sandboxes, and those who know what they are doing can opt out in order to reduce duplication of installs and cut down on build times. Addition of a `prefer-global-db` flag and a good default setting for it (i.e., false) seems to me like it would resolve the _central_ issue people have with the platform, and situate us well to unilaterally recommend it as the default install option. Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Mentors and thoughts on a GSoC proposal?
Hi all! We have the following GSoC proposal submitted to us: https://gist.github.com/fugyk/37510958b52589737274 Is there anyone on the cabal-devel list who would like to join as a mentor either to comment on this proposal, or feels up to mentoring this proposal (if we are to accept it, it will need a mentor with good familiarity with cabal internals)? Please let me know, or register on google melange and establish a connection to haskell.org if so. Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
An Easy Solution to PVP Bounds and Cabal Hell
Recently there has been some discussion about how we can fix the problem of “Cabal Hell”. Some people advocate restrictive upper bounds, to prevent packages from being broken by new updates. Some other people point out that too-restrictive bounds can lead to bad install plans, since some packages might want newer versions of some dependencies, and others older versions. Still other people say that we can _retroactively_ fix upper bounds (in either direction) by modifying cabal files using the new features in Hackage. Some people think this is a terrible idea because it looks like we are mutating things, and this confuses hashes. In turn, these people support either nix or a nix-like approach by which packages have hashes that encompass the full versions of all their transitive dependencies. With that in hand, we can cache builds and mix-and-match to build the precise environment we want for each package while reducing redundant computation. However, the cache of all the various binary combinations may still grow large! And none of this fully begins to address the dreaded “diamond dependency” problem. Here is a chart of some such solutions: http://www.well-typed.com/blog/aux/images/cabal-hell/cabal-hell-solutions.png One way to look at a particular build is in an n-dimensional state space (of the Hilbert sort) determined by all its dependencies, not least the compiler itself. The solver acts as a particle traversing this space. But this description is too simple. Our state of dependencies and constraints itself varies and grows over time. So another approach is to think of the dependencies as a transitive graph, where each node may vary along a time axis, and as they slide along the axis, this in turn affects their children. We now have not just one Hilbert space, but a collection of them related by branching trees as authors locally modify the dependencies of their packages. If we keep this simple model in mind, it is easy to see why everyone is always having these debates. Some people want to fix the graph, and others want to simplify it. Some people want an immutable store, and some people want to rebase. But we can’t “really” rebase in our current model. Bearing in mind our model of a space-time continuum of hackage dependences, the solution emerges — enforce immutability, but allow retroactive mutation. For instance, suppose Fred tries to install package Foo on Friday evening, but discovers that it depends on version 1.0 of Bar (released the previous Friday) that in turn depends on version 0.5 of Baz but Foo also depends on version 0.8 of Baz. So Fred branches Bar and changes the dependency, which in turn informs Betty, that there is also a 1.0 of Bar with different dependencies and we have forked our package timeline. On getting this message on Monday, Betty can merge by pushing with --force-rewrites and this goes back in the timeline and makes it so that Baz retroactively had the right dependencies and now Fred, as of the previous Friday, no longer has this problem. (That way he still has the weekend). Now the failed build is cut off temporarily into a cycle in the package timeline that is disconnected from the rewrite. We stash it with “hackage stash” until Monday at which time the dependency graph is 100 percent equalized and primed for new patches. At this point we unstash Foo as of Friday and it is replaced by the Foo from the new timeline. Friday Fred needs to remain stashed lest he run into himself. The longer he can be avoided by his Monday self the better. Future work could include bots which automate pruning of artifacts from redundant branches. If this description was too abrupt, here is a diagram with a fuller description of the workflow: http://bit.ly/15IIGac I know there are some new ideas to take in here, and there is a little technical work necessary to make it feasible, but in my opinion if you can understand the current cabal situation, and you can understand how git and darcs work, then you should be able to understand this too. Hopefully by this time next year, we’ll be able to say that our problems with cabal have been truly wiped from our collective memory. HTH, HAND. Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Making cabal-install SSL capable
So there are many discussions over various hackage security schemes, and there are a variety of takes on the different elements of how we could make package distribution more secure. However, everyone seems to agree that it would be unambiguously better if the cabal install executable were able to communicate over ssl. I looked at the previous discussion on this topic [1], and it seems that HsOpenSSL and tls were both considered. I don’t have any experience with how cross-platform compatible HsOpenSSL is (i.e. if it is sufficiently easy to use for both Windows and OS X that we can just encourage people to “cabal install cabal-install” and things will just work). I don’t know if anyone else can speak to this? Furthermore, of course, redistributing cabal-install binaries could potentially be more of a pain with links to external c libraries. I’m not quite sure how much an issue this would be. Meanwhile, tls is certainly cross-platform, but there is the question about how trustworthy it is, as it is not nearly as widely used and vetted as openssl. Also, we have the option of simply shelling out to curl, wget, or the appropriate powershell command (on windows 7 or above you get those by default). So rather than rely on either HsOpenSSL or tls, we could also teach cabal to probe for one of the appropriate executables on first run, save that configuration, and warn if no such executable is available (allowing the user to fall back to http with warnings indefinitely). I would like to pursue getting SSL into cabal by any of these three avenues. What do people feel about the relative tradeoffs of these options? Honestly, I lean towards simply using the tls package, because https is ultimately only going to be a complimentary aspect of our security architecture plans and not central to it. And a pure-haskell dependency is the most logical approach. If people find too much fault with that approach, I would be inclined to shell out as the next option, with HsOpenSSL as the last option only because I worry about too many “unknown unknowns” of the sort I listed above. But if others have more experience with these approaches, proposals are welcome! —Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
I don’t think the issue of http libraries as a foundational core library is very important. I suspect it would be possible to do a minimal http transport over tls, just as one can over HsOpenSSL, if that is how we decided to go. In the meantime, here are the first-order dependencies of tls alone, for comparison. I imagine there are a few others pulled in as well, in the second-order deps. cereal >= 0.4 , byteable , data-default-class -- crypto related , cryptohash >= 0.6 , crypto-random >= 0.0 && < 0.1 , crypto-numbers , crypto-cipher-types >= 0.0.8 , crypto-pubkey >= 0.2.8 , crypto-pubkey-types >= 0.4 , cipher-rc4 , cipher-des , cipher-aes >= 0.2 && < 0.3 -- certificate related , asn1-types >= 0.2.0 , asn1-encoding , x509 >= 1.5.0 && < 1.6.0 , x509-store >= 1.5.0 , x509-validation >= 1.5.1 && < 1.6.0 , async More troublesome, I recall that the current scheme for cabal is that it is fully bootstrappable by only depending on GHC base libs and “vendored” dependencies? In that case, perhaps we really should lean only towards the “shell out” solution. Or, I suppose, we could hide the ssl implementation behind a flag — but that feels rather awkward in comparison. So let’s try this: can anybody suggest any _downside_ to the “shell out” solution? —Gershom On April 28, 2015 at 9:22:22 AM, Herbert Valerio Riedel (hvrie...@gmail.com) wrote: > On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote: > > [...] > > > I have no intention of playing the "minimal dependency" game (though I > > don't mind dropping data-default, which accounts for 6 of the dependencies > > listed there). I will point out- as Gershom already did- that in many cases > > it's likely easier to install a few extra Haskell packages than it is to > > pull in OpenSSL as a dependency, especially on Windows. (And that's > > ignoring the fact that http-client-openssl exists.) > > While I do appreciate the technical issues resulting from HsOpenSSL on > Windows[1], I'll be frank and admit that there's a "political" aspect > that worries me with such a large number of added dependencies imported > into the cabal project in one go, as that would promote (or at the very > least bias) one specific family of multiple competing HTTP-client > abstractions into the Haskell Platform through the back-door (assuming > the idea of the HP hasn't been abandoned -- I may not be up to date > regarding that debate), and make it a fait accompli without having > actually had any agreement on it (which I admit may never be reached, as > the associated communities involved have grown quite large by now and > may disagree quite violently on basic design choices...). > > That's why I suggested HTTP+HsOpenSSL (which tbh is not my favorite HTTP > library), as that would be the neutral choice regarding HTTP-libraries > at the foundational core library level. Alternatively, Gershom's > suggestion to shell out to curl(1)/wget(1)/etc would equally achieve > impartiality regarding HTTP-libraries (and probably work better on > Windows too) > > PS: We shouldn't forget that there's also an existing deployed > cabal-install user-base we can't get rid off so easily, which may > still leak unencrypted basic-auth credentials for the years to > come. Just saying... > > [1]: Are those issues documented somewhere btw? Could that it be > addressed via minghc? > > Cheers, > hvr > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
Note that I’ve started some refactorings to support curl/wget/etc already. I’m not sure how best to keep these patches from stepping on one another’s toes. I’ll try to get my stuff to an unfinished, untested stopping point where nonetheless there is a clear extension point, and then perhaps a fork off of that branch would make sense? —Gershom On May 5, 2015 at 7:29:21 AM, Mikhail Glushenkov (the.dead.shall.r...@gmail.com) wrote: > Hi, > > On 4 May 2015 at 08:31, Michael Snoyman wrote: > > Just a little update on this. I pinged the author of publicsuffixlist > > (necessary for proper cookie domain handling) about removing the > > data-default dependency, and after discussion we decided to just merge the > > code into http-client instead. With that change, the full dependency list > > for http-client-openssl is in fact smaller that http-streams: > > I think we would accept a patch making cabal-install depend on > http-client or http-streams if it was enabled with a flag. > Refactorings required to make this work would also make it simpler to > add support for curl/wget/whatever. > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https We have some initial support for multibackend downloads and uploads both. Lots of bits are still missing, but the basic downloads work with curl and wget both, and the basic uploads with curl. The code regarding uploading build reports (which isn't in use anyway) is now commented out temporarily. Any work at adding other backends or further improving these (note the many TODO comments littering the code) can hopefully build on this. In particular, note there's an HttpTransportType, and a function `findHttpTransport`. In turn both `getHTTP` and `uploadToURI` now call this function, then case on the result to dispatch to different transports. All the transport specific logic should now be localized to those two places. This code is still rather ugly and could use some cleanup. But it should provide an extension point for using other https layers as well. On top of that, I haven't tackled the issue of making choice of transport configurable instead of just doing auto-discovery in a fixed order. It seems to me that this is something that could be added to the config file, or a command line flag, or both. So anyone that wants to fixate on that part of the problem, feel free to jump in :-) For my part, I wanted to get this out there to help anyone else interested in adding a transport. At this point, I intend mainly to just clean up what exists, fill in the powershell (and possibly bitsadmin) transport for windows, and then reenable HTTP as a fallback layer in some fashion (with warnings or confirmation or something). (I had commented out the layer entirely to make sure I wasn't missing any uses of it). Again, normally I wouldn't be sharing something in this halfway shape, but it seems useful to make it available for others interested in doing related work. Cheers, Gershom On Tue, May 5, 2015 at 10:15 AM, Gershom B wrote: > Note that I’ve started some refactorings to support curl/wget/etc already. > I’m not sure how best to keep these patches from stepping on one another’s > toes. I’ll try to get my stuff to an unfinished, untested stopping point > where nonetheless there is a clear extension point, and then perhaps a fork > off of that branch would make sense? > > —Gershom > > > On May 5, 2015 at 7:29:21 AM, Mikhail Glushenkov ( > the.dead.shall.r...@gmail.com) wrote: > > Hi, > > > > On 4 May 2015 at 08:31, Michael Snoyman wrote: > > > Just a little update on this. I pinged the author of publicsuffixlist > > > (necessary for proper cookie domain handling) about removing the > > > data-default dependency, and after discussion we decided to just merge > the > > > code into http-client instead. With that change, the full dependency > list > > > for http-client-openssl is in fact smaller that http-streams: > > > > I think we would accept a patch making cabal-install depend on > > http-client or http-streams if it was enabled with a flag. > > Refactorings required to make this work would also make it simpler to > > add support for curl/wget/whatever. > > ___ > > cabal-devel mailing list > > cabal-devel@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
The “Transport” data type you suggest seems like a good refactor. I’m less
certain about the use of ProgramDB — the documentation suggests it will only be
populated from command line flags in the “configure” step, or from .cabal
files. Since upload/download do not take place in such settings, I don’t think
it will contain useful information yet. So it might be the right approach to
use it, but it would also require, I suspect, modifying other parts of the
cabal-install executable to populate it properly?
—Gershom
On May 6, 2015 at 3:32:44 AM, Mikhail Glushenkov
(the.dead.shall.r...@gmail.com) wrote:
> On 6 May 2015 at 00:26, Gershom B wrote:
> > Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https
>
> Looks like a good first step. Consider using machinery in
> Distribution.Simple.Program.Db for searching for curl/wget in path or
> in user-provided location.
>
> I'd also use something like
>
> data Transport = { getHttp :: URI -> FilePath -> IO (Int, String),
> putHttp :: URI -> FilePath -> ...}
>
> configureTransport :: ProgramDB -> IO Transport
>
> instead of switching on TransportType in getHttp/uploadToUri.
>
___
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Cabal and simultaneous installations of the same package
For the info of all, here is the proposal: https://gist.github.com/fugyk/37510958b52589737274 The mentors are Ryan Trinkle and Thomas Tuegel. Hopefully as the project proceeds, Vishal will be checking in with us, asking questions and seeking clarification where necessary, etc. --Gershom On Thu, May 7, 2015 at 5:19 PM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote: > On 7 May 2015 at 22:34, Simon Peyton Jones wrote: > > Dear Cabal developers > > > > I guess everyone is busy, but I feel a bit stuck on knowing how to make > > progress on this thread. > > Vishal Agrawal's GSoC proposal has been accepted. I guess we'll have > to wait and see what comes out of it now. > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
On my branch now, everything "should" work: https://github.com/gbaz/Cabal/tree/https By "should" I mean the refactor is in place, and we have support for curl, wget, powershell, and insecure-http. You can pass a global flag to set your preferred transport (and it will not try insecure-http unless you explictly request it). If you use any transport but insecure-http it will convert http to https urls automatically. Things that remain outstanding 1) ETags are not enabled on the new transports -- this is just some tedious work to emit them from the programs and parse them out. 2) http-transport is a global option and can be passed, but it doesn't seem to wind up in the documentation correctly. Not sure how to configure the options properly. 3) Proxy support is not fully tested on curl/wget -- it _did_ work on my machine at one point, but it lives behind a particularly perverse proxy and ceased working in a way I can't diagnose and might just be due to a hopeless proxy. 4) I haven't properly tested upload support on wget, which is fiddly since it needs to do its own multipart encoding just like insecure-http. 5) Proxies are not enabled on powershell -- this is some tedious work to automate parsing out the proxy settings better, since the "correct powershell" way to handle proxies with user/passwords doesn't seem to actually work. 6) Powershell also needs real escaping, in case package names/urls perversely have quotation marks in them. Anyway, this touched a bunch of stuff in small ways and could use some review and _especially_ some testers across various platforms and transports to see what's still missing, If any brave souls want to try out the various transports, or pick up some of the remaining work, please do! This was a nice exercise, but I could really use another set or two of eyes/hands to take it to 100%. (note that even though I branched before the digest fix, I ported it over to this branch, so that the insecure-http transport _should_ be using digest auth properly already). --Gershom On Thu, May 7, 2015 at 5:02 AM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote: > Hi, > > On 6 May 2015 at 20:08, Thomas Tuegel wrote: > > The saved program configuration is not serialized in > > `dist/setup-config`, [1] so it must be regenerated at runtime every > > time, anyway. > > We don't want to configure all known built-in programs on each 'cabal > upload', though, so we should introduce a 'configTransport' function > to be used in 'uploadAction' instead of 'configCompiler'. > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
I've been happily using the curl backend for a bit now and it seems to work fine, so I'd like to get this polished and committed. Since the curl backend works, then even if the wget and powershell backends aren't fully tested, the workaround can just be to tell users to install curl and make sure it is in their path (or to pass the insecure-http option that falls back to the existing implementation). So perhaps we can just patch cabal to warn on using wget or powershell backends that if there are issues they should try one of the fully finished options, and then we can merge? Alternately, someone can jump in and try to give a hand with the other two backends -- they're very close. -g On Fri, May 8, 2015 at 12:46 PM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote: > On 8 May 2015 at 00:14, Gershom B wrote: > > On my branch now, everything "should" work: > > https://github.com/gbaz/Cabal/tree/https > > Thanks for working on this. I only had time to take a brief glance, > but everything looks good so far. Hope we can merge your patches soon. > > > (note that even though I branched before the digest fix, I ported it > over to > > this branch, so that the insecure-http transport _should_ be using digest > > auth properly already). > > You could've just rebased (which is a good practice anyway). > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Making cabal-install SSL capable
Done: https://github.com/haskell/cabal/pull/2613 :-) --Gershom On Mon, May 18, 2015 at 4:15 PM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote: > Hi, > > On 18 May 2015 at 20:22, Gershom B wrote: > > So perhaps we can just patch cabal to warn on using wget or powershell > > backends that if there are issues they should try one of the fully > finished > > options, and then we can merge? > > Sure, please send us a pull request. > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Improving the "Get Haskell Experience"
I’m ccing cabal-devel, as that list seems pertinent to this discussion too. In general I’m in favor of unifying efforts such as this. For windows, I’d still like the _option_ to get prebuilt library binaries for the full platform db. The modularity means that they can be just downloaded in a separate folder now, rather than installed into e.g. the global db? If so, that’s a nice win. Here is my motivation — I tried the minghc installer and it mainly worked, but it played terribly with cygwin, which I use pervasively. So I found myself in a situation where one set of paths worked with cygwin, and the other set of paths let me build the network library. I still have some anxieties about those sorts of issues, and being able to “just download the binaries” would make me feel a bit safer about at least one workaround should things get too muddled up. If we synchronize LTS and “platform libs,” then I would like A) some way of distinguishing “blessed platform libs” from “other libs in LTS” (to solve the “curation problem” which has always been a goal of the platform) and B) a standardized release schedule for LTS. (And, of course, I assume this will _not_ be for the platform release upcoming, which is due very shortly, but we’ll have a longer lead time to integrate and shake out all the various issues and test, etc.) —Gershom On July 12, 2015 at 12:04:22 PM, Mark Lentczner (mark.lentcz...@gmail.com) wrote: > *tl;dr: We'd like to incorporate stack into Haskell Platform, and stop > shipping pre-built packages, so we banish cabal hell, and have a single > common way to 'get Haskell' that just works.* > > At ICFP '14, there were several long group discussions of the state of > "getting Haskell", including Haskell Platform, Stackage, and other > approaches. Over the last year, there have been a few more public > discussions and evolution on the ideas, and other installer developments. > In particular, Stackage's LTS package sets are a direct development from > this work, and the release of stack has offered new options. > > Today, drawing from all this good work and ideas from so many, we'd would > like to propose a concrete plan: > > - Haskell Platform becomes the standard way to get *GHC* and related > tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a > user-friendly, cross-platform installer that gives a standard way to "get > Haskell" for most users. > - Use the *stack* model for package installation: > - The global db has only the GHC packages > - There is a package db for each curated set, Haskell Platform > becomes one such set > - Projects each have their own package db, much like sandboxes. > - Haskell Platform's installer will no longer include pre-built, > pre-installed packages other than GHC's set. Instead, it is configured so > that *stack* can be used to build and install, on as needed, the > corresponding Haskell Platform release packages. > > We think this plan solves many different community needs: > > - We have a clear way to "get Haskell" that works for a wide variety of > use cases. > - HP installer gets much smaller, and about as minimal as a working > installation can get. > - By leaving most packages out of the global database, users of > cabal-install, will now have far fewer problems. Sandbox builds should now > never give users "cabal hell" like warnings. > - By building and installing the Platform packages into it's own package > db, users get the benefit of building and installing these common packages > only once per system, yet can easily bypass them for any given project if > desired. > - Since the Platform packages are now built and installed as needed, > installing on smaller systems or servers without OpenGL will work. > > To do this, we have a bit of work ahead of us: We need to settle on > installation layout for each OS (including getting msys into the Windows > installer); decide on the naming and versioning of the Platform package set > (is it just LTS? does it have a different life cycle? etc...); getting > *stack* ready such a distribution; and configuring (or updating) > *cabal-install* to support the three-layer package db scheme. We think we > can do this in short order. > > We recognize this represents a significant change for the Platform, and > will require buy-in from the various parts, especially *ghc*, *cabal*, and > *stack*. We'd like to get your input. > > - Michael & Mark > ___ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Request for feedback on spec/proposal for distributing package collections via hackage
> and is there any point to having a collection without versions in it? (If Cabal syntax is extended to support depending on collections as well as packages, yes?) So I think another use-case for collections, besides "version-locked", is sets of "blessed" packages. So we might want a collection for "verified compatible with windows 2008" or "platform packages" or "works with nhc" to be collections. And in those cases, specifying unique versions doesn't seem to make much sense. And one could imagine taking intersections -- i.e. "uhc-compatible _and_ in stackage LTS". In general I like this proposal as very minimal in terms of just providing and collecting data, and allowing that data to then be used by clients in various ways. --gershom On Tue, Jul 14, 2015 at 3:02 PM, Edward Z. Yang wrote: > Hello Duncan, > > In my eyes, this proposal looks like some sort of generalization of > Stackage; and one further use case is "special purpose" collection. My > big question: how composable are these collections really? I can't put > two collections with conflicting versions together (or can I? Do I > union?); and is there any point to having a collection without versions > in it? (If Cabal syntax is extended to support depending on collections > as well as packages, yes?) > > The classic use-case for package collections is deployment settings, ala > Stack, or even Cargo lockfiles / Bundler Gemfile.lock (versioned > collections). In all these use-cases package collections are treated as > non-compositional things. http://doc.crates.io/guide.html > http://bundler.io/v1.7/rationale.html#checking-your-code-into-version-control > Libraries (compositional) do NOT publish lockfiles: only executables > (non-compositional) DO. > > Re the file format, it seems fine; suitable for the lockfile use-case > and the Stackage use-case. Less sure about the unioning semantics. > > Edward > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: cabal-install rebooted?
That _does_ look simpler! However, I think there are multiple efforts underway towards the nix-style stuff. We had a GSoC on that for example. And in that workflow, if it all works out properly, then we end up with a situation where since the general-user-db has no conflicts, then sandboxes are the tools that become generally not required. So I would be quite hesitant about moving things in the other direction... -g On Tue, Sep 8, 2015 at 1:16 PM, Bardur Arantsson wrote: > Hi all, > > So, I was feeling a bit frustrated about the complexity of the Cabal > sandbox code, and when I get frustrated I start deleting things... > > Just for funzies I tried deleting all the obvious non-sandbox code > in cabal-install, and here's the result: > > > https://github.com/BardurArantsson/cabal/commit/27aa116cc0ab3c824bd80c175ecbe51955dd9271 > > As you can see it means the removal of 218 lines, but most importantly > IMO it drastically simplifies the code in some places, notably > loadConfigOrSandboxConfig (funnily enough) becomes trivial and > classifyPackageEnvironment disappears (conincidence? I think not.). I'm > sure there are quite a few other things that could also be removed. I've > left a few notes sprinkled in the code marked by XXX. > > Obviously, this isn't mergeable as-is[1] and I mostly did it for a lark, > but what do you guys think? Is this something that could/should be > pursued further? I seem to recall hearing some rumblings that some > people really wanted cabal-install to be sandbox-only. I think this > little Proof of Concept shows that it would be beneficial at least from > a code complexity/maintenance perspective. > > (I certainly know that I've been getting really frustrated trying to > implement #2810 because the code is incredibly *gnarly* because it has > to account for a lot of combinations of things, and this might be a good > way to try to reverse the tide of option-itis.) > > Regards, > > /b > > [1] For one thing, there's need to be some sort of deprecation period of > non-sandbox mode at the very least. :) > > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Global Constraints for Cabal
Hi all. I've got a branch of cabal with a new feature: https://github.com/gbaz/cabal/tree/constraints-config This lets you either pass `constraints-file` on the command line or in the ~/.cabal/config file. The constraints-file serves as a "default" cabal.config file for freezes should one not be provided by a particular package. Thus, a "minimal" platform can ship with a file that includes the platform constraints. Later, a user can simply download a new file for a new constraints set -- say lts -- and swap their config to point to that instead. This makes both the platform in its new ideally-more-minimal guise and stackage play nicer together and with cabal, in a way that required minimal changes to cabal proper. Ideally this or a relative can land soon to help enable the minimal platform plans (the work grew out of the discussion on: https://github.com/haskell/haskell-platform/issues/206) There are two places where I wasn't quite sure what to do. In PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile doesn't check if this flag is set and handle that case. So this is when we are already in a sandbox and the question is if we should _also_ respect this flag, just as a sandbox also respects a cabal.config file directly in the directory. My gut says "don't respect it in sandboxes" but i'm not sure. Additionally, the freezePackages function in Freeze.hs doesn't respect this flag. I'm not sure exactly what the full call chain here is yet, so haven't worked out the logic. Anyway, thoughts? --gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Global Constraints for Cabal
I've changed Freeze.hs to also respect this flag, and submitted a pull request: https://github.com/haskell/cabal/pull/2820 --Gershom On Thu, Sep 10, 2015 at 6:45 PM, Gershom B wrote: > Hi all. I've got a branch of cabal with a new feature: > https://github.com/gbaz/cabal/tree/constraints-config > > This lets you either pass `constraints-file` on the command line or in > the ~/.cabal/config file. > > The constraints-file serves as a "default" cabal.config file for > freezes should one not be provided by a particular package. > > Thus, a "minimal" platform can ship with a file that includes the > platform constraints. Later, a user can simply download a new file for > a new constraints set -- say lts -- and swap their config to point to > that instead. > > This makes both the platform in its new ideally-more-minimal guise and > stackage play nicer together and with cabal, in a way that required > minimal changes to cabal proper. > > Ideally this or a relative can land soon to help enable the minimal > platform plans (the work grew out of the discussion on: > https://github.com/haskell/haskell-platform/issues/206) > > There are two places where I wasn't quite sure what to do. In > PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile > doesn't check if this flag is set and handle that case. So this is > when we are already in a sandbox and the question is if we should > _also_ respect this flag, just as a sandbox also respects a > cabal.config file directly in the directory. My gut says "don't > respect it in sandboxes" but i'm not sure. > > Additionally, the freezePackages function in Freeze.hs doesn't respect > this flag. I'm not sure exactly what the full call chain here is yet, > so haven't worked out the logic. > > Anyway, thoughts? > > --gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Global Constraints for Cabal and also Release Plan?
Any more feedback on this? And also, do we have any plans for an upcoming Cabal release? Braindump here: Once this lands and we have a cabal release, we can do a trial run of a new minimal platform release. So I'm inclined to try to target a cabal release for sooner than later if possible, to enable trying to get the "minimal platform" proposal happening. A "nice to have" in the future for the platform would be to help address https://github.com/haskell/haskell-platform/issues/207 The proposal there would be to add an env variable (perhaps CABAL_PATH_PREFIX) which, if it existed, would be added to the path before running child processes (such as those kicked off by build-type:configure). That way windows environments could provide the Msys2 bin directory and those tools would then be made available to the configure scripts, etc. I haven't investigated adding this yet, but I don't think it would be too much work. If people are open to this, and especially if there were some pointers, I'd be happy to look at this. In any case, this is only a "nice to have" since it can be worked around with an explicit "switcher script" prior to running cabal-install. Anyway, what are people's thoughts on A) getting the "global constraints" PR added (https://github.com/haskell/cabal/pull/2820), B) possibly adding the cabal-path-prefix logic, and C) a release timetable with or without B so as to enable facilitate a minimal platform release? -g On Fri, Sep 11, 2015 at 5:17 PM, Gershom B wrote: > I've changed Freeze.hs to also respect this flag, and submitted a pull > request: > > https://github.com/haskell/cabal/pull/2820 > > --Gershom > > On Thu, Sep 10, 2015 at 6:45 PM, Gershom B wrote: >> Hi all. I've got a branch of cabal with a new feature: >> https://github.com/gbaz/cabal/tree/constraints-config >> >> This lets you either pass `constraints-file` on the command line or in >> the ~/.cabal/config file. >> >> The constraints-file serves as a "default" cabal.config file for >> freezes should one not be provided by a particular package. >> >> Thus, a "minimal" platform can ship with a file that includes the >> platform constraints. Later, a user can simply download a new file for >> a new constraints set -- say lts -- and swap their config to point to >> that instead. >> >> This makes both the platform in its new ideally-more-minimal guise and >> stackage play nicer together and with cabal, in a way that required >> minimal changes to cabal proper. >> >> Ideally this or a relative can land soon to help enable the minimal >> platform plans (the work grew out of the discussion on: >> https://github.com/haskell/haskell-platform/issues/206) >> >> There are two places where I wasn't quite sure what to do. In >> PackageEnvironment.hs, the tryLoadSandboxPackageEnvironmentFile >> doesn't check if this flag is set and handle that case. So this is >> when we are already in a sandbox and the question is if we should >> _also_ respect this flag, just as a sandbox also respects a >> cabal.config file directly in the directory. My gut says "don't >> respect it in sandboxes" but i'm not sure. >> >> Additionally, the freezePackages function in Freeze.hs doesn't respect >> this flag. I'm not sure exactly what the full call chain here is yet, >> so haven't worked out the logic. >> >> Anyway, thoughts? >> >> --gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Global Constraints for Cabal and also Release Plan?
On September 24, 2015 at 11:01:53 AM, Bardur Arantsson (s...@scientician.net) wrote: > On 09/22/2015 12:11 AM, Gershom B wrote: > [--snip--] > > > > The proposal there would be to add an env variable (perhaps > > CABAL_PATH_PREFIX) which, if it existed, would be added to the path > > before running child processes (such as those kicked off by > > build-type:configure). That way windows environments could provide the > > Msys2 bin directory and those tools would then be made available to > > the configure scripts, etc. > > > > I'm not sure I understand... what does CABAL_PATH_PREFIX add over just > adding whatever is needed to the $PATH before executing cabal? > > (Without having looked at the issue thread.) > > I'm mainly worried about option-itis... which cabal-install is already > suffering a lot from. This is a fine question. By the way, I realized this might better be served as a cabal-path-prefix option (in cabal config) rather than an env variable, since that is more uniform. In any case, the issue is this. Suppose I want to work with MSys2, as MinGHC does. This is what lets me build against various c libraries, even in a windows environment. To do so, I need all the MSys2 tools in my path. So far, so good. But… those tools overlap in name with other tools in my path. For example, with my existing cygwin installation. And also with other tools of the same names at times that are the _windows_ versions of those common utilities. So, I want MSys2 tools in my path but _only_ when I am building cabal packages, and not otherwise. Either I manually modify my env each time I want to build a cabal package, _or_ we teach cabal to be clever and handle it for us, which is the motivation for this. Certainly, if we want a good “out of the box” experience for windows users, asking them to modify their path before they run cabal, every time they do so, is not a very great experience. —gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Global Constraints for Cabal and also Release Plan?
On September 24, 2015 at 11:52:51 AM, Mikhail Glushenkov (the.dead.shall.r...@gmail.com) wrote: > On 24 September 2015 at 17:06, Gershom B wrote: > > So, I want MSys2 tools in my path but _only_ when I am building cabal > > packages, and not > otherwise. > > IIUC, 'extra-prog-path' in '~/.cabal/config' already does what you > want. It looks like it also supports multiple directories, using comma > as separator. Hmm… we should investigate if that is sufficient, or if it can be changed to do so. Consider for example if we have a configure build-type, that runs an autoconf script. It is not enough that the executable we run be in the path, but also that the “path” available to the autoconf script be amended as well. So if this only changes where _cabal_ searches for executables, but does not affect the path made available to them, I think this will be insufficient? The potential overlap is certainly worth investigating, though. -g ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Global Constraints for Cabal and also Release Plan?
On September 24, 2015 at 12:16:29 PM, Mikhail Glushenkov (the.dead.shall.r...@gmail.com) wrote: > On 24 September 2015 at 17:56, Gershom B wrote: > > Consider for example if we have a configure build-type, that runs an > > autoconf script. > It is not enough that the executable we run be in the path, but also that the > “path” available > to the autoconf script be amended as well. > > Yes, 'extra-prog-path' also affects the PATH environment variable of > the programs invoked by cabal-install: > > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Run.hs#L177 > > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Program/Db.hs#L344 > > https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Simple/Configure.hs#L808 > Ah this looks like it only takes hold for the simple build-type and not “build-type: configure” for use with autoconf. (i.e. the “building network” case). I don’t quite see what’s going on in terms of how anything is implemented yet, but I would take it there would be no objections to extending this to handle the “build-type: configure” case? And of course I’d welcome any pointers as to what needs to be changed to make that work.. -gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Global Constraints for Cabal and also Release Plan?
On September 25, 2015 at 5:43:38 PM, Gershom B (gersh...@gmail.com) wrote: > Ah this looks like it only takes hold for the simple build-type and not > “build-type: configure” > for use with autoconf. (i.e. the “building network” case). I don’t quite see > what’s going > on in terms of how anything is implemented yet, but I would take it there > would be no objections > to extending this to handle the “build-type: configure” case? And of course > I’d welcome > any pointers as to what needs to be changed to make that work.. And this is now implemented here: https://github.com/haskell/cabal/pull/2840 —Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: ANN: cabal-install-1.22.6.0 has been released
Well, it’s worse than that. The recent releases haven’t come with any official binaries at all. So if we wanted to make the official Cabal binaries more prominent (good idea) then we should actually generate and link to those binaries (which takes work). This relates to the discussion I’ve been kicking off about getting some unified and shared build infrastructure so we can crank those binaries out with less work. Until that point though, we should maybe raid halcyon’s builds to actually provide some binaries for the latest releases :-) —gershom On November 10, 2015 at 12:33:24 AM, Miëtek Bak (mie...@bak.io) wrote: > Dear Ryan, > > The Cabal download page hasn’t been updated for a while. > https://www.haskell.org/cabal/download.html > > I think it’d make sense to remove the exhaustive list of platforms supported > by Halcyon > from this page, and make the links to official Cabal binaries more prominent. > > If any mention of Halcyon should be kept on the page at all, perhaps it could > be a short note > at the very end of the cabal-install section, saying something to the effect > of “cabal-install > can also be installed with Halcyon”. > > Regards, > > -- > Miëtek > https://mietek.io > > > > > > On 2015-06-18, at 01:32, Miëtek Bak wrote: > > > > Thanks. cabal-install 1.22.6.0 (and 1.22.5.0) can now be installed with > > Halcyon: > > > > halcyon install --cabal-version=1.22.6.0 > > > > Supported platforms include: > > > > - Amazon Linux 2014.09 > > - Arch Linux > > - CentOS 6, 7 > > - Debian 6, 7, 8 > > - Gentoo Linux > > - openSUSE 13.2 > > - OS X 10.8, 10.9, 10.10 > > - Red Hat Enterprise Linux 6, 7 > > - Slackware 14.1 > > - SUSE Linux Enterprise Server 12 > > - Ubuntu 12.04 LTS, 14.04 LTS, 14.10, 15.04 > > - Fedora 20, 21 > > > > > > -- > > Miëtek > > https://mietek.io > > > > > > > > > > On 2015-06-17, at 09:21, Ryan Thomas wrote: > > > >> Hi all, > >> > >> A new minor release of cabal-install has been released, this is to > >> pick up a fix for @ezyang's fix for #2502. > >> > >> This is now available on hackage and the downloads page and the > >> sha1sum is listed below. > >> > >> Cheers, > >> > >> ryan > >> > >> > >> d474b0eef6944af1abef92419cea13cee50993f3 cabal-install-1.22.6.0.tar.gz > >> ___ > >> cabal-devel mailing list > >> cabal-devel@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > > > > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Fwd: Haskell Platform Plans
Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest --- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated bu
Re: Wanted: cabal-install 1.24.0.0 binary for OS X
I've emailed Mikhail with a binary. Assuming it works, then nobody else should need to :-) Cheers, Gerhsom On Wed, May 4, 2016 at 3:30 PM, Mikhail Glushenkov wrote: > Hi *, > > I've uploaded cabal-install 1.24.0.0 binaries for Linux and Windows > (both i386 and x86-64) to https://www.haskell.org/cabal/download.html. > I'd also like to upload an OS X binary, but I don't have access to an > OS X machine currently. Can someone please build an OS X binary for > cabal-install 1.24.0.0 and e-mail it to me? Thanks in advance. > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: [ANN] Cabal and cabal-install 1.24.0.0 have been released
the cabal-latest directory should probably be updated as well, and particularly the doc section: https://www.haskell.org/cabal/release/cabal-latest/ I also note that the docs haven't built on hackage for Cabal, and it would be nice to upload those I guess..? --gershom On Mon, May 2, 2016 at 7:32 AM, Ryan Thomas wrote: > Hi all, > > Cabal and cabal-install 1.24.0.0 have been released. > > These have been uploaded to hackage, tagged in the repo and updated on the > downloads page. > > The changelog is quite extensive, so please see here and here for the > complete details. > > Cheers, > > ryan > > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel > ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Opening up Cabal development
On July 13, 2016 at 7:32:47 PM, Edward Z. Yang (ezy...@mit.edu) wrote: The general notion sounds good to me. I’m semi-indifferent between (1) and (2) though conservatively lean towards the latter. > - The Travis build must always be green. We should prioritize > adding more tests for things we care about. Look into regular > Hackage tests. > - PR all your changes (so that you can check that Travis is green), > try to get approval for big changes but BE BOLD. I’d add - I don’t break backwards compat for APIs without notice and discussion, and don’t break backwards compat for any element of cabal files without lots of discussion. (and I don’t know what tests would be necessary to help notice this, but they’d probably be useful!) —gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
cabal release binaries for 1.24.0.2 ?
I noticed that there there are no binaries for 1.24.0.2 and in fact the webpage still links the source tarball for 1.24.0.1 as the latest? It would be good to get this fixed. —Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: cabal release binaries for 1.24.0.2 ?
It seems like the binaries (aside from the os x one) aren't up yet. It would be good to have them for the new ghc and platform. --gershom On Sat, Jan 7, 2017 at 4:12 PM, Mikhail Glushenkov wrote: > Hi, > > On 7 January 2017 at 21:02, Gershom B wrote: >> I noticed that there there are no binaries for 1.24.0.2 > > I'll build them tomorrow. BTW, can you please send me an OS X binary > for 1.24.0.2? > >> the webpage still links the source tarball for 1.24.0.1 as the latest? > > Fixed. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
new cabal install binaries
when we build the new platform we're going to have new cabal-install binaries for 2.0.1.0. It would be better if we provided the same ones as provided on the cabal website. Is there anyone lined up to build any of these, or would you like the platform team to provide you with the binaries we build as well? (i know i've done mac in the past, and will happily do so again, but typically there have been other sources for linux and windows binaries). Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
draft proposal on provenance-qualified dependencies
Hey all, I mentioned (on the long SLURP thread) that I was thinking about a general proposal for provenance-qualified dependencies to reduce coupling in the haskell ecosystem. Having worked it out a bit, I think the bigger win is it also provides a way to specify dependencies on git repos, etc., which has been an oft-requested feature. I don't want to submit it as an ecosystem proposal proper without further polish, and I held off on bugging a larger audience of cabal folks until the 2.2 branch was cut. So now I'm passing this along for further comment and polish before I make a real proposal: https://github.com/gbaz/ghc-proposals/blob/patch-1/proposals/-provenance-qualified-imports.rst There's no urgency, but it would be good to get some feedback in the next few weeks if possible. Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: draft proposal on provenance-qualified dependencies
Thanks for these comments Simon. It is good to have a sanity-check on these proposals before they go before a broad audience. I'll try to take them into account and submit this properly as a proposal (including creating the associated discussion thread) in the next few days. If anyone else has any thoughts (bear in mind this involves cross-cutting changes across cabal files and a bit of ghc) please send them on. On "Does a particular build have to use packages from one repo only?" -- the idea is that _per package_ a provenance may be specified to a specific repo. If no provenance is specified, then there is the current existing "search path-like" functionality where a chain of overlays may live over a repo. The proposal does not address that, because it is how things work already -- although arguably, the way in which this works may be insufficiently understood among existing cabal users? (In fact, looking at the cabal documentation, I see that the description of multiple remote repos doesn't specify the manner in which they are combined, which it should). Cheers, Gershom On Fri, Feb 23, 2018 at 6:26 AM, Simon Peyton Jones wrote: > Gershom > > Looks like a great idea. > > Lots of questions though: > > > - I think more motivation would be helpful. E.g. "You are in change > of the GHC 8.6 release. Package authors don't want to upload a new > version of their packages until 8.6 is out, but you still want to > smoke-test 8.6 against their packages. Doing so requires some minor > changes (version bounds, changes in base-library APIs etc); so you > want to be able to make these changes in a sandbox that won't hurt > anyone". Or something like that. > > Maybe describe other use-cases. It's *much* easier to evaluate > a proposal when I'm totally clear what it's for. > > - Does a particular build have to use packages from one repo only? > Or is there something like a "search path"? > > Thanks! > > Simon > > | -Original Message- > | From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On Behalf > | Of Gershom B > | Sent: 19 February 2018 00:26 > | To: cabal-devel > | Subject: draft proposal on provenance-qualified dependencies > | > | Hey all, I mentioned (on the long SLURP thread) that I was thinking > | about a general proposal for provenance-qualified dependencies to > | reduce coupling in the haskell ecosystem. Having worked it out a bit, > | I think the bigger win is it also provides a way to specify > | dependencies on git repos, etc., which has been an oft-requested > | feature. > | > | I don't want to submit it as an ecosystem proposal proper without > | further polish, and I held off on bugging a larger audience of cabal > | folks until the 2.2 branch was cut. So now I'm passing this along for > | further comment and polish before I make a real proposal: > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > | b.com%2Fgbaz%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F- > | provenance-qualified- > | imports.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d > | 28508d5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967 > | 936143539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi > | LCJBTiI6Ik1haWwifQ%3D%3D%7C- > | 1&sdata=cH0gNADmzA%2BTkmXZEDY6lLYUTx2D2KX%2B3T8KO%2FvU86s%3D&reserved= > | 0 > | > | There's no urgency, but it would be good to get some feedback in the > | next few weeks if possible. > | > | Cheers, > | Gershom > | ___ > | cabal-devel mailing list > | cabal-devel@haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcabal- > | devel&data=04%7C01%7Csimonpj%40microsoft.com%7C64fd20012b9a4b24d28508d > | 5772f6cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636545967936143 > | 539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi > | I6Ik1haWwifQ%3D%3D%7C- > | 1&sdata=fgfMNTNt%2BwEQ5PaTKxtl0bmO7wDv9sBiMUnWSbJhcnE%3D&reserved=0 ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: draft proposal on provenance-qualified dependencies
I've updated the proposal with increased motivation as suggested, and submitted it to the repo. Here is the discussion thread: https://github.com/ghc-proposals/ghc-proposals/pull/115 --g On Fri, Feb 23, 2018 at 11:03 AM, Simon Peyton Jones wrote: > | current existing "search path-like" functionality where a chain of > | overlays may live over a repo. The proposal does not address that, > | because it is how things work already -- although arguably, the way in > | which this works may be insufficiently understood among existing cabal > | users? > > Well I can say with certainty that it's insufficiently understood by /this/ > cabal user. > > I had no idea there could be more than one repo, which 'cabal update' caches > locally. > > Simon > > | -Original Message- > | From: Gershom B [mailto:gersh...@gmail.com] > | Sent: 23 February 2018 15:02 > | To: Simon Peyton Jones > | Cc: cabal-devel > | Subject: Re: draft proposal on provenance-qualified dependencies > | > | Thanks for these comments Simon. It is good to have a sanity-check on > | these proposals before they go before a broad audience. I'll try to > | take them into account and submit this properly as a proposal > | (including creating the associated discussion thread) in the next few > | days. If anyone else has any thoughts (bear in mind this involves > | cross-cutting changes across cabal files and a bit of ghc) please send > | them on. > | > | On "Does a particular build have to use packages from one repo only?" > | -- the idea is that _per package_ a provenance may be specified to a > | specific repo. If no provenance is specified, then there is the > | current existing "search path-like" functionality where a chain of > | overlays may live over a repo. The proposal does not address that, > | because it is how things work already -- although arguably, the way in > | which this works may be insufficiently understood among existing cabal > | users? (In fact, looking at the cabal documentation, I see that the > | description of multiple remote repos doesn't specify the manner in > | which they are combined, which it should). > | > | Cheers, > | Gershom > | > | On Fri, Feb 23, 2018 at 6:26 AM, Simon Peyton Jones > | wrote: > | > Gershom > | > > | > Looks like a great idea. > | > > | > Lots of questions though: > | > > | > > | > - I think more motivation would be helpful. E.g. "You are in change > | > of the GHC 8.6 release. Package authors don't want to upload a > | new > | > version of their packages until 8.6 is out, but you still want to > | > smoke-test 8.6 against their packages. Doing so requires some > | minor > | > changes (version bounds, changes in base-library APIs etc); so you > | > want to be able to make these changes in a sandbox that won't hurt > | > anyone". Or something like that. > | > > | > Maybe describe other use-cases. It's *much* easier to evaluate > | > a proposal when I'm totally clear what it's for. > | > > | > - Does a particular build have to use packages from one repo only? > | > Or is there something like a "search path"? > | > > | > Thanks! > | > > | > Simon > | > > | > | -Original Message- > | > | From: cabal-devel [mailto:cabal-devel-boun...@haskell.org] On > | > | Behalf Of Gershom B > | > | Sent: 19 February 2018 00:26 > | > | To: cabal-devel > | > | Subject: draft proposal on provenance-qualified dependencies > | > | > | > | Hey all, I mentioned (on the long SLURP thread) that I was > | thinking > | > | about a general proposal for provenance-qualified dependencies to > | > | reduce coupling in the haskell ecosystem. Having worked it out a > | > | bit, I think the bigger win is it also provides a way to specify > | > | dependencies on git repos, etc., which has been an oft-requested > | > | feature. > | > | > | > | I don't want to submit it as an ecosystem proposal proper without > | > | further polish, and I held off on bugging a larger audience of > | cabal > | > | folks until the 2.2 branch was cut. So now I'm passing this along > | > | for further comment and polish before I make a real proposal: > | > | > | > | > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > | > | hu > | > | b.com%2Fgbaz%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F- > | > | provenance-qualified- > | > | >
windows cabal binaries and upcoming cabal-install release
No binaries were built for the 2.4.0.0 release -- I assume with the upcoming release we'll have proper binaries. Just wanted to drop a note to _highly recommend_ that at least the windows cabal-install binaries in the next release be built with ghc 8.6.2 since I think that changes in the core libs will mean that cabal-install will work better with homedirs with a wider range of characters. Just talked to someone about this five minutes ago, so its fresh in my mind :-) Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: [Patch] Fix estimator explanation
Sorry for the slow response time. I know you've been on this for a while. I've now committed those changes to master and they'll be in the next redeploy. Thanks! --Gershom On Sun, Feb 3, 2019 at 4:22 PM Francesco Ariis wrote: > > Good evening hackage developers, > please consider merging this patch to hackage-server. > The rationale (and the patch itself) is very simple: to point to the > more precise (and more clear) documentation for the chosen estimator. > Thanks > -F > ___ > cabal-devel mailing list > cabal-devel@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
downloads.haskell.org now moved
The migration of the downloads box to packet is now done. Rather than uploading to downloads-origin.haskell.org, binaries should now go to downloads-packet-origin.haskell.org. The former will be decommissioned soon-ish. This applies for cabal and ghc binaries both. Login for the `cabal` and `ghc` accounts on the box is sftp-only. Let me know if there's any problems. Cheers, Gershom ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
