Shipments in Cabal

Krasimir Angelov

7 Dec 2005 7 Dec '05

3:39 p.m.

Hello Guys, I have started developing Shipments in Cabal. It is working like it was discussed previously. When there are multiple *.cabal files, in the directory where the Setup.lhs lies, then they all will be build in dependency order. Packages that contain both executables and libraries are deprecated. In order to keep the backward compatibility the package description parser returns a list of PackageDescription. In the list there is one element for the library and one element for each executable. The package name for the executables is equal to the "executable" field in the corresponding stanza in the package description file. The trouble that I see is with the bindir, libdir, etc directory names. They all may depend on $pkgid value which is different for each package in the shipment. The consequence is that by default all binaries will be installed in their own directories. I think it is better to install them in common directory instead. It might be better if we were able to use $shipment variable instead of $pkgid. Another possible usage of is in "sdist" command. By default the "sdist" command is building the ${pkgid}.tar.gz archive. In presence of multiple packages I think it should build one common package: ${shipment}.tar.gz. The problem is how to guess the $shipment value. There are some ideas: a> The shipment name might be kept in some special file. b> In HSQL I am using package names like: hsql, hsql-odbc, hsql-mysql, ..... One solution is to use the common prefix in the package names as shipment name. When there is only one package, then the shipment name will be equal to the package name. The advantage is that, when the shipment name is encoded in the package name, then for the user it will be easier to find the package sources. The drawback is that we have to force some restriction on the package names. c> Another solution is to use the name of the top level directory. The drawback is that the user can't rename the top level directory. Any ideas? Cheers, Krasimir

Show replies by date

Isaac Jones

8 Dec 8 Dec

1:02 p.m.

Krasimir Angelov writes:

...

Hello Guys,

I have started developing Shipments in Cabal.

Awesome! FWIW, you should probably take a look at the package dependency code in cabal-get, and you also might want to look at the new cabal-install tool, as I expect that when we ship a cabal w/ cabal-install, people will use it a lot. Although having shipments makes cabal-install less important. The smarts in cabal-get is that it checks to see what's already installed, and this might not really be desirable for a shipment (unless we want to have a flag for only installing the necessary stuff). BTW, could you open a new ticket or wiki page at the cabal wiki / ticket tracker: http://hackage.haskell.org/cgi-bin/trac/trac.cgi/report/3

...

It is working like it was discussed previously. When there are multiple *.cabal files, in the directory where the Setup.lhs lies, then they all will be build in dependency order.

Are you using a temporary package-conf file?

...

Packages that contain both executables and libraries are deprecated.

Sounds good.

...

In order to keep the backward compatibility the package description parser returns a list of PackageDescription. In the list there is one element for the library and one element for each executable. The package name for the executables is equal to the "executable" field in the corresponding stanza in the package description file.

I see. You didn't want to break backward compatibility w/ the PackageDescription type?

...

The trouble that I see is with the bindir, libdir, etc directory names. They all may depend on $pkgid value which is different for each package in the shipment. The consequence is that by default all binaries will be installed in their own directories. I think it is better to install them in common directory instead. It might be better if we were able to use $shipment variable instead of $pkgid. Another possible usage of is in "sdist" command. By default the "sdist" command is building the ${pkgid}.tar.gz archive. In presence of multiple packages I think it should build one common package: ${shipment}.tar.gz.

The problem is how to guess the $shipment value. There are some ideas:

a> The shipment name might be kept in some special file.

I kinda like this, package.cabalship (or whatever) might look like: shipment: shipmentname version: 1.1 -- inherited by the packages if they have no version num copyright -- ditto The only down side I see to this is that if version can be in the shipment, and need not be in the .cabal files, then the .cabal files are no longer stand-alone (they need the shipment file). OTOH, if you have a scheme where you want to have version numbers the same across all packages in your shipment, well then it would be very nice to not have to specify it in each .cabal file. What are the advantages of having standalone .cabal files within a shipment? I don't see anything too big unless someone wants to be able to grab just part of the shipment, but in that case, they could just get the .cabalship file anyway. The other advantage is that .cabal files would not be backward compatible w/ older cabals but I guess that older cabals will already break in the presence of multiple .cabal files in a directory, so maybe it doesn't matter. Opinions.

...

b> In HSQL I am using package names like: hsql, hsql-odbc, hsql-mysql, ..... One solution is to use the common prefix in the package names as shipment name. When there is only one package, then the shipment name will be equal to the package name. The advantage is that, when the shipment name is encoded in the package name, then for the user it will be easier to find the package sources. The drawback is that we have to force some restriction on the package names.

I don't really like the idea of forcing them to name their packages in a particular way. For instance, you might have a package cabal but want an executable install-cabal. We don't want to force people to use particular names for their binaries.

...

c> Another solution is to use the name of the top level directory. The drawback is that the user can't rename the top level directory.

Another simple idea is that we could add a shipment: field to the .cabal file. This would cause some redundancy between .cabal files, but that's nicer than b> or c>. Of course, shipment: wouldn't have to be in each file; it would just be required that one of the files has that field in it, but that's not very neat / symmetric. Also, have you thought about how one might specify that they only want to operate on one part of the package (a single .cabal file?). Maybe defaultSetup could take optional command-line option which is the .cabal file(s) to operate on, and if none are specified, then use *.cabal. This is where the cabal-get dependency code could come in handy. Let's say I have a shipment with A.cabal, B.cabal, and C.cabal where A depends on B and B depends on C. I already have C installed for some strange reason, it would be nice to say: ./setup configure A.cabal B.cabal ./setup build ./setup install and that should work just fine, because C is already installed. OTOH, if you said: ./setup configure A.cabal ./setup build ./setup install then setup should complain that you don't have B. This is something like how cabal-install works. I can say: cabal-install foo/foo.cabal bar/bar.cabal --user --prefix=/home/ijones/usr peace, isaac

Duncan Coutts

1:29 p.m.

On Thu, 2005-12-08 at 10:02 -0800, Isaac Jones wrote:

...

Krasimir Angelov writes:

...
Hello Guys,

I have started developing Shipments in Cabal.

Awesome! FWIW, you should probably take a look at the package dependency code in cabal-get, and you also might want to look at the new cabal-install tool, as I expect that when we ship a cabal w/ cabal-install, people will use it a lot. Although having shipments makes cabal-install less important.

I also wrote a bit about this issue: http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables I started off from the assumption that "shipments" are necessary and obviously beneficial. However after thinking about it for a while and thinking through some of the implications (especially on dependency resolution) I'm not not so convinced that we need shipments as such. There is certainly a case for making it easier to work with a system/project that consists of multiple libraries and executables, however I'm convinced that the cabal package should be the fundamental unit and that "shipments" should be merely for the convenience of the developer. I would certainly like to see better support in Cabal for larger projects (for one thing I'd love to be able to convert Gtk2Hs to use Cabal) but I think we should be careful to fully understand the changes we intend to make to support larger projects. Duncan

Isaac Jones

2:04 p.m.

Duncan Coutts writes:

...

On Thu, 2005-12-08 at 10:02 -0800, Isaac Jones wrote:

...
Krasimir Angelov writes:

...
Hello Guys,

I have started developing Shipments in Cabal.

Awesome! FWIW, you should probably take a look at the package dependency code in cabal-get, and you also might want to look at the new cabal-install tool, as I expect that when we ship a cabal w/ cabal-install, people will use it a lot. Although having shipments makes cabal-install less important.

I also wrote a bit about this issue:

http://haskell.org/hawiki/Cabal_2fMultiPackageDistributables

I started off from the assumption that "shipments" are necessary and obviously beneficial. However after thinking about it for a while and thinking through some of the implications (especially on dependency resolution) I'm not not so convinced that we need shipments as such.

There is certainly a case for making it easier to work with a system/project that consists of multiple libraries and executables,

however I'm convinced that the cabal package should be the fundamental unit and that "shipments" should be merely for the convenience of the developer.

This is actually why I wrote cabal-install, I wanted to try out the idea of leaving .cabal packages as the fundamental unit and building this layered tool for convenience. It doesn't do dependency analysis yet, and it doesn't install in a temporary location, but you can say: cabal-install foo.tgz bar.tgz -- etc (it'll also accept .tar, .tar.gz, .cabal, and a directory name) The main advantage of shipments, IMO, is that they're lighter-weight than multiple packages. I'm still somewhat torn, but leaning toward shipments, especially if it can pretty much be a layer on top of .cabal files. Moving the version into .cabalship breaks this somewhat. I was planning to gain some experiences w/ cabal-install before pushing into shipments, but Krasimir jumped into it. I think they're more important for the visual studio plugin than for other stuff. peace, isaac

Krasimir Angelov

2:16 p.m.

2005/12/8, Isaac Jones :

...

Krasimir Angelov writes:

...
Hello Guys,

I have started developing Shipments in Cabal.

Awesome! FWIW, you should probably take a look at the package dependency code in cabal-get, and you also might want to look at the new cabal-install tool, as I expect that when we ship a cabal w/ cabal-install, people will use it a lot. Although having shipments makes cabal-install less important.

The smarts in cabal-get is that it checks to see what's already installed, and this might not really be desirable for a shipment (unless we want to have a flag for only installing the necessary stuff).

BTW, could you open a new ticket or wiki page at the cabal wiki / ticket tracker: http://hackage.haskell.org/cgi-bin/trac/trac.cgi/report/3

Yes. I will.

...

...
It is working like it was discussed previously. When there are multiple *.cabal files, in the directory where the Setup.lhs lies, then they all will be build in dependency order.

Are you using a temporary package-conf file?

It should but the dependency checking isn't implemented yet.

...

...
In order to keep the backward compatibility the package description parser returns a list of PackageDescription. In the list there is one element for the library and one element for each executable. The package name for the executables is equal to the "executable" field in the corresponding stanza in the package description file.

I see. You didn't want to break backward compatibility w/ the PackageDescription type?

The PackageDescription type is changed. The library and executables fields are removed. There is a new field content :: PackageContent. The PackageContent is something like: data PackageContent = Library { ..... } | Executable { .... } I just want keep backward compatibility in the package description file syntax.

...

I kinda like this, package.cabalship (or whatever) might look like:

shipment: shipmentname version: 1.1 -- inherited by the packages if they have no version num copyright -- ditto

The only down side I see to this is that if version can be in the shipment, and need not be in the .cabal files, then the .cabal files are no longer stand-alone (they need the shipment file).

I would like to avoid the need for extra description files. The version and copyright fields doesn't make sense for me providing that each package has its own version, copyright, etc.

...

...
b> In HSQL I am using package names like: hsql, hsql-odbc, hsql-mysql, ..... One solution is to use the common prefix in the package names as shipment name. When there is only one package, then the shipment name will be equal to the package name. The advantage is that, when the shipment name is encoded in the package name, then for the user it will be easier to find the package sources. The drawback is that we have to force some restriction on the package names.

I don't really like the idea of forcing them to name their packages in a particular way. For instance, you might have a package cabal but want an executable install-cabal. We don't want to force people to use particular names for their binaries.

...
c> Another solution is to use the name of the top level directory. The drawback is that the user can't rename the top level directory.

Another simple idea is that we could add a shipment: field to the .cabal file. This would cause some redundancy between .cabal files, but that's nicer than b> or c>.

I like the idea for "shipment" field since it is a light weight solution. The redundancy is not high and I can't see any reason why we shouldn't allow to have .cabal files from different shipments in one directory. In this case the sdist command will simply create multiple .tar.gz files. If the "shipment" field is missing then the default value will be equal to $pkgid.

...

Also, have you thought about how one might specify that they only want to operate on one part of the package (a single .cabal file?). Maybe defaultSetup could take optional command-line option which is the .cabal file(s) to operate on, and if none are specified, then use *.cabal.

This is where the cabal-get dependency code could come in handy. Let's say I have a shipment with A.cabal, B.cabal, and C.cabal where A depends on B and B depends on C. I already have C installed for some strange reason, it would be nice to say:

./setup configure A.cabal B.cabal ./setup build ./setup install

and that should work just fine, because C is already installed. OTOH, if you said:

./setup configure A.cabal ./setup build ./setup install

then setup should complain that you don't have B.

Yes. In Visual Haskell, I will need some way to specify that I want to build only one of the packages. Cheers, Krasimir

Isaac Jones

5:36 p.m.

Isaac Jones writes:

...

...
a> The shipment name might be kept in some special file.

I kinda like this, package.cabalship (or whatever) might look like:

shipment: shipmentname version: 1.1 -- inherited by the packages if they have no version num copyright -- ditto

Another thing we could do w/ a shipment file is specify the location of .cabal files so you can have them in their own source tree. So if you had a source tree like: src/foo/ foo.hs foo.cabal src/bar/ bar.hs bar.cabal then you could have src/foobar.cabalship: shipment: foobar cabal-files: bar/bar.cabal, foo/foo.cabal peace, isaac

7105

Age (days ago)

7106

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Duncan Coutts
Isaac Jones
Krasimir Angelov