ANNOUNCE: yackage 0.0.0

Hi all, I was speaking with my coworker Yitz[1] about a project he's working on. Basically, he's going to end up with about 16 cabal packages that are not going to be deployed to Hackage, and wanted us to set up a Hackage server for our company to deploy these kinds of things. However, getting all the pieces of Hackage aligned properly for such a simple use case seemed a bit overkill. I then realized that I had the exact same problem during Yesod development: before I make a major release, I usually end up with about 10-15 packages that are not yet live on Hackage. It gets to be a real pain when suddenly wai-extra is depending on network 2.3 and authenticate requires network 2.2, and suddenly I need to manually recompile 10 packages. So I decided to write up a simple web service to act as a local Hackage server. It has no security (anyone with access can upload a package), doesn't build haddocks, doesn't show package descriptions, etc. All it does is: Show a list of uploaded packages/versions Links to the tarballs Allows you to upload new versions, which will automatically overwrite existing packages Provides the 00-index.tar.gz file needed by cabal-install, as well as the tarballs for all the packages In order to use this, just do the following: cabal install yackage run "yackage" Upload your packages Add remote-repo: yackage:http://localhost:3500/ to your ~/.cabal/config file cabal update Install your packages are usual You'll need to leave yackage running whenever you want to run an update or download new packages. A few other usage notes: If you overwrite a package, your cache folder will still have the old version. You might want to just wipe our your cache folder on each usage. Running cabal update will download the update for both yackage and the main hackage server; the latter can be a long process depending on your internet connection. Here's a little shell script that will disable the Hackage repo, wipe our the Yackage cache, update and re-enable the Hackage repo: #!/bin/sh CABAL_DIR=~/.cabal cp $CABAL_DIR/config $CABAL_DIR/config.sav sed 's/^remote-repo: hackage/--remote-repo: hackage/' < $CABAL_DIR/config.sav > $CABAL_DIR/config rm -rf $CABAL_DIR/packages/yackage cabal update cp $CABAL_DIR/config.sav $CABAL_DIR/config I hope others find this tool useful. Michael [1] http://www.haskellers.com/user/Yitz_Gale/

This is very interesting. I was thinking if this could work like an
overlayed "namespace" on top of Hackage, rather than a complete override,
that it would be a very interesting way to "fork" Hackage so it does what
you want, transparently, and as a proxy. Is that actually how it works
though? (It might be that I've not had my coffee yet, but I'm a little
fuzzy on that point).
While the Haskell-platform is a great stabilizing technology for the Haskell
community and gives a nice warm fuzzy feeling to those who want to try it in
commercial settings, it's not always true that it provides enough
functionality for everyone's needs, and being able to somewhat modify what's
available on Hackage could be very valuable.
Dave
On Mon, Dec 27, 2010 at 8:41 AM, Michael Snoyman
Hi all,
I was speaking with my coworker Yitz[1] about a project he's working on. Basically, he's going to end up with about 16 cabal packages that are not going to be deployed to Hackage, and wanted us to set up a Hackage server for our company to deploy these kinds of things. However, getting all the pieces of Hackage aligned properly for such a simple use case seemed a bit overkill.
I then realized that I had the exact same problem during Yesod development: before I make a major release, I usually end up with about 10-15 packages that are not yet live on Hackage. It gets to be a real pain when suddenly wai-extra is depending on network 2.3 and authenticate requires network 2.2, and suddenly I need to manually recompile 10 packages.
So I decided to write up a simple web service to act as a local Hackage server. It has no security (anyone with access can upload a package), doesn't build haddocks, doesn't show package descriptions, etc. All it does is:
Show a list of uploaded packages/versions Links to the tarballs Allows you to upload new versions, which will automatically overwrite existing packages Provides the 00-index.tar.gz file needed by cabal-install, as well as the tarballs for all the packages
In order to use this, just do the following:
cabal install yackage run "yackage" Upload your packages Add remote-repo: yackage:http://localhost:3500/ to your ~/.cabal/config file cabal update Install your packages are usual
You'll need to leave yackage running whenever you want to run an update or download new packages. A few other usage notes:
If you overwrite a package, your cache folder will still have the old version. You might want to just wipe our your cache folder on each usage. Running cabal update will download the update for both yackage and the main hackage server; the latter can be a long process depending on your internet connection.
Here's a little shell script that will disable the Hackage repo, wipe our the Yackage cache, update and re-enable the Hackage repo:
#!/bin/sh
CABAL_DIR=~/.cabal
cp $CABAL_DIR/config $CABAL_DIR/config.sav sed 's/^remote-repo: hackage/--remote-repo: hackage/' < $CABAL_DIR/config.sav > $CABAL_DIR/config rm -rf $CABAL_DIR/packages/yackage cabal update cp $CABAL_DIR/config.sav $CABAL_DIR/config
I hope others find this tool useful.
Michael
[1] http://www.haskellers.com/user/Yitz_Gale/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

There is also the hackage 2.0 code [1]. This can be easily
cabal-installed, and added as an extra remote-repo to your
.cabal/config file. We've set this up at typLAB [2], and it's working
great. Cabal upload doesn't support multiple remote repo's, but we've
created a small deployment utility to quickly deploy to our own
hackage. By careful version number management, you can also create
local forks of hackage packages.
Erik
[1] http://hackage.haskell.org/trac/hackage/wiki/HackageDB
[2] http://www.typlab.com
On Mon, Dec 27, 2010 at 17:53, David Leimbach
This is very interesting. I was thinking if this could work like an overlayed "namespace" on top of Hackage, rather than a complete override, that it would be a very interesting way to "fork" Hackage so it does what you want, transparently, and as a proxy. Is that actually how it works though? (It might be that I've not had my coffee yet, but I'm a little fuzzy on that point). While the Haskell-platform is a great stabilizing technology for the Haskell community and gives a nice warm fuzzy feeling to those who want to try it in commercial settings, it's not always true that it provides enough functionality for everyone's needs, and being able to somewhat modify what's available on Hackage could be very valuable. Dave
On Mon, Dec 27, 2010 at 8:41 AM, Michael Snoyman
wrote: Hi all,
I was speaking with my coworker Yitz[1] about a project he's working on. Basically, he's going to end up with about 16 cabal packages that are not going to be deployed to Hackage, and wanted us to set up a Hackage server for our company to deploy these kinds of things. However, getting all the pieces of Hackage aligned properly for such a simple use case seemed a bit overkill.
I then realized that I had the exact same problem during Yesod development: before I make a major release, I usually end up with about 10-15 packages that are not yet live on Hackage. It gets to be a real pain when suddenly wai-extra is depending on network 2.3 and authenticate requires network 2.2, and suddenly I need to manually recompile 10 packages.
So I decided to write up a simple web service to act as a local Hackage server. It has no security (anyone with access can upload a package), doesn't build haddocks, doesn't show package descriptions, etc. All it does is:
Show a list of uploaded packages/versions Links to the tarballs Allows you to upload new versions, which will automatically overwrite existing packages Provides the 00-index.tar.gz file needed by cabal-install, as well as the tarballs for all the packages
In order to use this, just do the following:
cabal install yackage run "yackage" Upload your packages Add remote-repo: yackage:http://localhost:3500/ to your ~/.cabal/config file cabal update Install your packages are usual
You'll need to leave yackage running whenever you want to run an update or download new packages. A few other usage notes:
If you overwrite a package, your cache folder will still have the old version. You might want to just wipe our your cache folder on each usage. Running cabal update will download the update for both yackage and the main hackage server; the latter can be a long process depending on your internet connection.
Here's a little shell script that will disable the Hackage repo, wipe our the Yackage cache, update and re-enable the Hackage repo:
#!/bin/sh
CABAL_DIR=~/.cabal
cp $CABAL_DIR/config $CABAL_DIR/config.sav sed 's/^remote-repo: hackage/--remote-repo: hackage/' < $CABAL_DIR/config.sav > $CABAL_DIR/config rm -rf $CABAL_DIR/packages/yackage cabal update cp $CABAL_DIR/config.sav $CABAL_DIR/config
I hope others find this tool useful.
Michael
[1] http://www.haskellers.com/user/Yitz_Gale/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

This was brought up on reddit[1]. Anyone who is interested in the
differences should feel free to look there.
Michael
[1] http://www.reddit.com/r/haskell/comments/es3of/announcing_yackage_your_perso...
On Mon, Dec 27, 2010 at 9:24 PM, Erik Hesselink
There is also the hackage 2.0 code [1]. This can be easily cabal-installed, and added as an extra remote-repo to your .cabal/config file. We've set this up at typLAB [2], and it's working great. Cabal upload doesn't support multiple remote repo's, but we've created a small deployment utility to quickly deploy to our own hackage. By careful version number management, you can also create local forks of hackage packages.
Erik
[1] http://hackage.haskell.org/trac/hackage/wiki/HackageDB [2] http://www.typlab.com
On Mon, Dec 27, 2010 at 17:53, David Leimbach
wrote: This is very interesting. I was thinking if this could work like an overlayed "namespace" on top of Hackage, rather than a complete override, that it would be a very interesting way to "fork" Hackage so it does what you want, transparently, and as a proxy. Is that actually how it works though? (It might be that I've not had my coffee yet, but I'm a little fuzzy on that point). While the Haskell-platform is a great stabilizing technology for the Haskell community and gives a nice warm fuzzy feeling to those who want to try it in commercial settings, it's not always true that it provides enough functionality for everyone's needs, and being able to somewhat modify what's available on Hackage could be very valuable. Dave
On Mon, Dec 27, 2010 at 8:41 AM, Michael Snoyman
wrote: Hi all,
I was speaking with my coworker Yitz[1] about a project he's working on. Basically, he's going to end up with about 16 cabal packages that are not going to be deployed to Hackage, and wanted us to set up a Hackage server for our company to deploy these kinds of things. However, getting all the pieces of Hackage aligned properly for such a simple use case seemed a bit overkill.
I then realized that I had the exact same problem during Yesod development: before I make a major release, I usually end up with about 10-15 packages that are not yet live on Hackage. It gets to be a real pain when suddenly wai-extra is depending on network 2.3 and authenticate requires network 2.2, and suddenly I need to manually recompile 10 packages.
So I decided to write up a simple web service to act as a local Hackage server. It has no security (anyone with access can upload a package), doesn't build haddocks, doesn't show package descriptions, etc. All it does is:
Show a list of uploaded packages/versions Links to the tarballs Allows you to upload new versions, which will automatically overwrite existing packages Provides the 00-index.tar.gz file needed by cabal-install, as well as the tarballs for all the packages
In order to use this, just do the following:
cabal install yackage run "yackage" Upload your packages Add remote-repo: yackage:http://localhost:3500/ to your ~/.cabal/config file cabal update Install your packages are usual
You'll need to leave yackage running whenever you want to run an update or download new packages. A few other usage notes:
If you overwrite a package, your cache folder will still have the old version. You might want to just wipe our your cache folder on each usage. Running cabal update will download the update for both yackage and the main hackage server; the latter can be a long process depending on your internet connection.
Here's a little shell script that will disable the Hackage repo, wipe our the Yackage cache, update and re-enable the Hackage repo:
#!/bin/sh
CABAL_DIR=~/.cabal
cp $CABAL_DIR/config $CABAL_DIR/config.sav sed 's/^remote-repo: hackage/--remote-repo: hackage/' < $CABAL_DIR/config.sav > $CABAL_DIR/config rm -rf $CABAL_DIR/packages/yackage cabal update cp $CABAL_DIR/config.sav $CABAL_DIR/config
I hope others find this tool useful.
Michael
[1] http://www.haskellers.com/user/Yitz_Gale/
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
David Leimbach
-
Erik Hesselink
-
Michael Snoyman