hackage, package list, trac, some suggestions/questions

[Duncan Coutts]

On Sat, 2008-05-31 at 00:21 +0100, Claus Reinke wrote:
> > Yes.  In the meantime, feel free to file feature requests as guest.
> 
> done.

Great, thanks.

>  though i notice that uninstall (#106, now #234), which i
> considered essential, is still lingering there a year later..

Make sure you note that is is essential for you on that ticket. We do
need help from our user base to help us rank the development priorities.
We only have limited developer time.

> > No, but here are some rough figures on failures (for the latest version
> > of each package):
> 
> thanks, that was interesting. btw, i fully expect such statistics
> to reflect infrastructure issues at least as much as package author
> issues, including overlap between the two where authors try to
> cope with infrastructure hickups.
> 
> so, having such statistics in generated in a prominent place
> would both
> 
> - alert package authors and users
> - alert cabal/hackage/haddock/ghc/.. maintainers

I agree such information should be given to package authors/maintainers
but I'd be a bit reluctant to see that done with the current
information. Package authors would probably not appreciate being told
their package does not work for essentially incorrect reasons and we'd
have to spend a lot of time fixing those things (like missing libs,
incorrect build orders).

I am working on fixing some of theses issues, but by replacing the
current build reporting system.

> >> 5. generally, i've always thought that hackage works the
> >>     wrong way round; instead of yet another push-based
> >>     place for people to put and forget copies of things, it
> >>     should work as a pull-based cache:
> >
> > It's a place for maintainers to put their releases (there may not even
> > be a another place to pull from).  It seems to me entirely appropriate
> > that maintainers should assume responsibility for that.
> 
> i had forgotten that hackage was the first to provide a space
> for authors without webspace access. but these days, there is
> code.haskell.org, and that seems to be a much better home
> for any package than a tarball described by a .cabal file.

Hackage has always been about a place to release packages not as
somewhere to host development repositories. It's based on things like
CPAN, linux distro package archives etc. It is not like sourceforge.

> why should all releases be centralised?

It provides many advantages. Simply having a central list is very
useful. Having a central list along with a tarball and meta-data allows
clients like cabal-install. It also gives us the opportunity to automate
things like gathering of build results which would be much harder when
packages are scattered all across the internet.

> why should package authors have to remember to think of copies on
> hackage? and why should hackage tarballs be the only release venue??

It is not the only release venue. Many packages are released in multiple
locations. If package authors do not want to take advantage of releasing
via hackage they do not need to do so.

Also, anyone can set up a hackage server. There are in-house
installations. The benefit of a public hackage server are maximised by
having one central one.

> authors/maintainers should assume responsibility for coding,
> registering packages with hackage, and indicating when a
> package is in a release state, so that hackage and alternative
> clients can fetch updated packages and do their thing.

Indicating when a package is in a release state is pretty easy:

cabal sdist
cabal upload dist/foo-1.0.tar.gz

> but if no authors chime in, there's probably no case yet
> against this "hackage owns everything" approach..

I don't see it as owning anything. In particular because it is only a
release venue and not a general hosting venue like sourceforge.

> > The email address on the package is merely copied from the .cabal file,
> > which is also publically available.  If a maintainer wants to hide this,
> > they need to obfuscate it in the .cabal file.
> 
> good point. as .cabal files are served as text, they might be
> scanned as well. still, i'd think that hackage should do as good
> mailing list archives do: obfuscate email addresses to make
> harvesting more difficult, without users having to obfuscate
> things by hand.
>
> if someone figures out how to install the package descriptions
> on their own machine for harvesting, there isn't much to be done
> about that, just as with harvesters registering on mailing lists.
> but one shouldn't make it too easy..

File a ticket, suggest an obfuscation method.


Duncan