Re: [Haskell-cafe] ANNOUNCE: yackage 0.0.0
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_personal_hackage_server/c1ah7gi On Mon, Dec 27, 2010 at 9:24 PM, Erik Hesselink wrote: > 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 >> >> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: yackage 0.0.0
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 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: yackage 0.0.0
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
[Haskell-cafe] 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
