non-hackage cabal repos? unpacking non-repo package tarballs?
I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages. 1. The simplest approach would be if cabal could expose its internal 'unpackPackage' as a command, so that author: cabal sdist user: cabal unpackPackage Example.tar.gz would work (the point being that cabal handles .tar.gz, which not all users have installed separately; distributing the .tar.gz would be handled via the usual channels; and after unpacking, cabal can build the source package). Note that 'cabal unpack' does not seem helpful here, as it touches the package index instead of just looking at the tarball. Could this be made possible, please? Or is it already? 2. Failing that, I remembered that cabal used to be designed without a fixed package repo address, and a little digging found options --remote-repo and --local-repo, as well as the directory layout for package repositories: http://hackage.haskell.org/trac/hackage/wiki/HackageDB So this scenario seems possible, in principle: author: expose a package repo http://myrepo user: cabal --remote-repo=http://myrepo fetch Example Is it possible to add a (temporary) repo location like this, especially for 'cabal fetch'/'cabal unpack'? I've managed to get 'cabal --local-repo=myrepo list Example' to work (needs uncompressed 00-index.tar), but not the remote variant, and fetching from the local repo doesn't work, either. Are there any usage examples of these features? Claus
On 2 November 2010 19:02, Claus Reinke
1. The simplest approach would be if cabal could expose its internal 'unpackPackage' as a command, so that
author: cabal sdist user: cabal unpackPackage Example.tar.gz [...] 2. Failing that, I remembered that cabal used to be designed without a fixed package repo address, and a little digging found options --remote-repo and --local-repo, as well as the directory layout for package repositories:
http://hackage.haskell.org/trac/hackage/wiki/HackageDB
So this scenario seems possible, in principle:
author: expose a package repo http://myrepo user: cabal --remote-repo=http://myrepo fetch Example
Both examples sound nice. I am also interested in which can be done. Whence Hackage 2.0 comes out, it may be possible to upload a Hackage package that's more of a demo and then cabal install clausreinke/foo, perhaps. I know there will at least be a separation of package types in terms of stability. I suppose this as it seems wise to keep as much Haskell code available in the central Hackage server as reasonably possible, it's done nothing but serve the Haskell ecosystem well so far, I think. I think in the general case right now, people tend to create a Github repo, or so I have observed, and that hasn't seemed to have a negative effect, so maybe it's not a big deal at all, to distribute examples in Cabal packages.
On Tue, Nov 2, 2010 at 11:02 AM, Claus Reinke
I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages.
1. The simplest approach would be if cabal could expose its internal 'unpackPackage' as a command, so that
author: cabal sdist user: cabal unpackPackage Example.tar.gz
This is possible with cabal-dev (http://goo.gl/RkLGx), but it's somewhat of an accidental feature, so it's not quite as simple as your ideal: Author: $ cabal sdist The user's side of things changes a bit depending on what the package is. If it's an executable, this works: User: $ cabal-dev add-source Example.tar.gz $ cabal-dev install Example $ ./cabal-dev/bin/example-program If you're distributing a binary, then the add-source is really all it takes, if you're happy using cabal-dev for the whole build. It will create a local sandbox with the new library, and subsequent cabal-dev commands can use that sandbox for all non-global packages. --Rogan
would work (the point being that cabal handles .tar.gz, which not all users have installed separately; distributing the .tar.gz would be handled via the usual channels; and after unpacking, cabal can build the source package).
Note that 'cabal unpack' does not seem helpful here, as it touches the package index instead of just looking at the tarball.
Could this be made possible, please? Or is it already?
2. Failing that, I remembered that cabal used to be designed without a fixed package repo address, and a little digging found options --remote-repo and --local-repo, as well as the directory layout for package repositories:
http://hackage.haskell.org/trac/hackage/wiki/HackageDB
So this scenario seems possible, in principle:
author: expose a package repo http://myrepo user: cabal --remote-repo=http://myrepo fetch Example
Is it possible to add a (temporary) repo location like this, especially for 'cabal fetch'/'cabal unpack'? I've managed to get 'cabal --local-repo=myrepo list Example' to work (needs uncompressed 00-index.tar), but not the remote variant, and fetching from the local repo doesn't work, either.
Are there any usage examples of these features?
Claus
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Christopher Done -
Claus Reinke -
Rogan Creswick