On Sun, May 29, 2011 at 11:13 AM, Duncan Coutts
On Fri, 2010-11-19 at 11:16 -0600, Antoine Latter wrote:
I'm not sure I really understand the difference. Whether there is a difference in content/meaning or just a difference in the format.
Oh my, what an old thread. I'll try an resurrect my state of mind at the time. I think my main concern was, as you said, a difference in format not a difference in substance. I also might have thrown in a good amount of over-engineering as well. What it comes down to is that embedding relative URLs (or even absolute URLs) in a tar-file feels like an odd thing to do - I don't see what advantage is has over a flat text file, and I can no longer create/consume the tar-file with standard tools. But maybe this doesn't matter - can we re-state what goals we're trying to get to, and what problems we're trying to solve? Going back into this thread I'm not even sure what I was talking about. Are we trying to come up with a master plan of allowing cabal-install to interact with diverse sources of packages-which-may-be-installed data? I'm imagining the following use cases: 1. hackage.haskell.org 2. a network share/file system path with a collection of packages 3. an internet url with a collection of packages 4. an internet url for a single package 5. a tarball with a collection of packages 6. a tarball with a single package 7. an untarred folder containing a package (as in 'cabal install' in my dev directory) With the ability to specify some of these in the .cabal/config or at the command line as appropriate. There's going to be some overlap between these cases, almost certainly. Am I missing any important cases? Are any of these cases unimportant? The next question would be how much effort do we require of the provider of a specific case? So for numbers 4 & 5, is the output of 'cabal sdist' good enough? For numbers 2 & 3, will I be able to just place package tgz files into a particular folder structure, or will I need to produce an index file? What are other folks doing? I don't know much about ruby gems. Microsoft's new 'NuGet' packages supports tossing packages in a directory and then telling Visual Studio to look there (they also support pointing the tools at an ATOM feed, which was interesting). Antoine
Duncan