cabal-upload & cabal-install

Hia Ross, Bjorn, Pepe Iborra and I were hacking on cabal-install today. I hope you like our patches :-). Pepe updated it to use filepath so it'd work on windows and I fiddled with locations of config and things to try and make installation simpler so it'll work "out of the box". I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it. However I failed to upload Cabal-1.1.6.2 which I also released today. Via both the website and cabal-upload interfaces it failed the upload after a few 100k, so I think it's a server side issue. Does it have a limit on the upload size? cabal-1.1.6.2.tar.gz is just over 500k. You can grab it here and try: http://haskell.org/cabal/release/latest/cabal-1.1.6.2.tar.gz My general impression is that cabal-install, hackage and cabal-upload are really nice, especially the hackage web ui. You've done a lot of work! What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it. One longer term thing I was thinking about was using hackage and cabal-install to gather testing feedback. We could have cabal-install report (with user consent) build successes and failures, including useful info about the environment, including the platform, Haskell implementation and version, the version of cabal, cabal-install and versions of the all the dependent packages (not sure if it should be directly or transitively). This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine. Duncan

On Thu, May 03, 2007 at 09:45:28PM +0100, Duncan Coutts wrote:
What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it.
I think slowly building the user base among early adopters (as now) will be the most useful. There's a GSoC project to extend the web interface, which will involve changes and the risk of temporary breakage. We won't be ready for everyone till after that. As far as I know, the main thing missing from cabal-install is documentation. There's a tricky issue of how it should relate to a system package manager, but that will have to wait.
One longer term thing I was thinking about was using hackage and cabal-install to gather testing feedback. We could have cabal-install report (with user consent) build successes and failures, including useful info about the environment, including the platform, Haskell implementation and version, the version of cabal, cabal-install and versions of the all the dependent packages (not sure if it should be directly or transitively).
This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine.
Sounds like a great idea. Another possibility is to have buildbots feeding this info back for all packages.

On Fri, 2007-05-04 at 00:27 +0100, Ross Paterson wrote:
On Thu, May 03, 2007 at 09:45:28PM +0100, Duncan Coutts wrote:
What do we need to do next? Should we invite a little bit of wider testing on cabal-install + hackage and get some user feedback. If that's good we should actively advertise and push it.
I think slowly building the user base among early adopters (as now) will be the most useful. There's a GSoC project to extend the web interface, which will involve changes and the risk of temporary breakage. We won't be ready for everyone till after that.
Right, sure. So just get Haskell hackers using it for the moment, hackers who are tolerant of a bit of churn.
As far as I know, the main thing missing from cabal-install is documentation. There's a tricky issue of how it should relate to a system package manager, but that will have to wait.
I think it should default to --user-install. Partly just because this means it'll "Just Work"tm for everyone without supplying additional options and without confusing error messages (like /usr/local: permission denied).
This would be a great way to do distributed testing and a way of finding out which packages are well used and tested. If summary info is on the website it also allows users to find out if a package is likely to work on their machine.
Sounds like a great idea. Another possibility is to have buildbots feeding this info back for all packages.
Although the number of people we ought to be able to get using cabal-install is probably orders of magnitude greater than the number we can get as buildbot clients. Duncan

On May 3, 2007, at 22:45 , Duncan Coutts wrote:
... I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it.
I think that's just a problem with the versioned dependency in cabal- upload.cabal. HTTP-3000.0.0 should already have those exports. Feel free to fix it (I don't have a lot of time right now with the baby). /Björn

On Fri, 2007-05-04 at 10:10 +0200, Bjorn Bringert wrote:
On May 3, 2007, at 22:45 , Duncan Coutts wrote:
... I was also trying cabal-upload. I found that cabal-upload needs some functions from the HTTP lib that are not actually exported. In particular the stuff to do with authorisation in the Browser module. It looks like it ought to be exported since it isn't actually used internally. When I do patch the HTTP lib to export that, cabal-upload works for me. I uploaded filepath-1.0 today using it.
I think that's just a problem with the versioned dependency in cabal- upload.cabal. HTTP-3000.0.0 should already have those exports. Feel free to fix it
Right ok. I'll fix the version of cabal-upload's http dep.
(I don't have a lot of time right now with the baby).
And congratulations! :-) Duncan
participants (3)
-
Bjorn Bringert
-
Duncan Coutts
-
Ross Paterson