Build system idea

[John Meacham]

On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote:
> The important thing about Cabal's way of specifying dependencies is that  
> they can be made sound with not much difficulty.  If I say that my 
> package depends on base==3.0 and network==1.0, then I can guarantee that 
> as long as those dependencies are present then my package will build.  
> ("but but but..." I hear you say - don't touch that keyboard yet!)

I can easily achieve this with autoconf or even nothing, I can simply do
a test to see if a system is running fedora core 9 using ghc 6.8.2 and
be assured that my package will build properly. But this misses the
entire point, I want my package to build not on my exact system, I want
it to build on _other_ peoples systems. People running with compilers and
libraries and on operating systems I never heard of.

However, this has the huge flaw of requiring a closed universe. A
complete and universal definition of what 'network == 1.0' means for all
time that all future compilers must agree on. It places a huge burden on
implementors to provide a 'network=1.0' compatible interface, simply so
cabal doesn't complain even though all programs would be happy with a
jhc-network 0.7 or a internet-5.0 package. It means that with
jhc-network which has 90% of the functionality of network, including
everything that 99.9% of all programs need every program will have to
either know about jhc-network to edit their cabal file to include it
conditionally, or they just won't work at all.

Note, this is similar to the problem of symbol versioning placed on
shared libraries. There is a fair amount of literature on the subject,
most unix's .so's used to have something similar to the current cabal model, a
version number with a minor/major part. it was found to lead to dll
hell. (well, .so hell) and we don't want to be in the place with haskell
(package hell?). Linux hence switched to its current system that
has an individual version number for every api function. I am not saying
that is the solution for haskell, but I do not see the current cabal
approach scaling any better than the old unix one and leading to the
same problems.


> Suppose you used autoconf tests instead.  You might happen to know that  
> Network.Socket.blah was added at some point and write a test for that, 
> but alas if you didn't also write a test for Network.Socket.foo (which 
> your code uses but ends up getting removed in network-1.1) then your code 
> breaks.  Autoconf doesn't help you make your configuration sound, and you 
> get no prior guarantee that your code will build.

And with cabal it breaks there in addition to another 80% of times when
it could have worked just fine. The autoconf feature test is strictly
superior here. 

> Now, Cabal's dependencies have the well-known problem that they're  
> exceptionally brittle, because they either overspecify or underspecify, 
> and it's not possible to get it "just right".  On the other hand, 
> autoconf configurations tend to underspecify dependencies, because you 
> typically only write an autoconf test for something that you know has 
> changed in the past - you don't know what's going to change in the 
> future, so you usually just hope for the best.  For Cabal I can ask the 
> question "if I modify the API of package P, which other packages might be 
> broken as a result?", but I can't do that with autoconf.

But the only reason they are broken is due to cabal's sledgehammer
approach to package versioning. There is no reason an autoconf style
system couldn't do the same thing.

And again, you are assuming you can even enumerate all the packages that
exist to find out which might be broken and what does that really give
you in any case? By changing the API you know you are going to break
some things, but what about all the company internal software out there
that uses haskell? you can't look at all their packages. It just does
not seem like a very useful thing to ask. as it is a question that can
be answered by 'grep'.


> Both systems are flawed, but neither fundamentally.  For Cabal I think it 
> would be interesting to look into using more precise dependencies  
> (module.identifier::type, rather than package-version) and have them  
> auto-generated.  But this has difficult implications: implementing  
> cabal-install's installation plans becomes much harder, for example.


Again, I would like to see this as another option. I think there are
interesting ideas in cabal about configuration management. But there
needs to be room for alternates including old standby's like autoconf


>
>>> So I accept that we do not yet cover the range of configuration choices
>>> that are needed by the more complex packages (cf darcs), but I think
>>> that we can and that the approach is basically sound. The fact that we
>>> can automatically generate distro packages for hundreds of packages is
>>> not insignificant. This is just not possible with the autoconf approach.
>>
>> This is just utterly untrue. autoconfed packages that generate rpms,
>> debs, etc are quite common. The only reason cabal can autogenerate
>> distro packages for so many is that many interesting or hard ones just
>> _arn't possible with cabal at all_.
>
> Exactly!  Cabal is designed so that a distro packager can write a program 
> that takes a Cabal package and generates a distro package for their 
> distro.  It has to do distro-specific stuff, but it doesn't typically 
> need to do package-specific stuff.
>
> To generate a distro package from an autoconf package either the package  
> author has to include support for that distro, or a distro packager has 
> to write specific support for that package.  There's no way to do generic 
> autoconf->distro package generation, like there is with Cabal.

In cabal you only get it because you convinced the cabal people to put
in code to support your distro. Which isn't much different than asking
the package manager too.

And besides, this ability has nothing to do with cabal's configuration
management capabilities, simply its metadata format. which can easily be
abstracted out and not tied to cabal. (which I would love to see.
cabal has a lot of good ideas, but due to its design, its bad ideas are
complete showstoppers rather than things you can replace)

and there are many automatic package managers for autoconf style
packages.

http://www.toastball.net/toast/ is a good one, it even downloads
dependencies from freshmeat when needed. in fact, your projects can
probably be auto installed by 'toast projectname' and you didn't even
know it!

http://encap.org/ - one I use on pretty much all my systems. since it is
distro independent.



> Yes this means that Cabal is less general than autoconf.  It was quite a  
> revelation when we discovered this during the design of Cabal - 
> originally we were going to have everything done programmatically in the 
> Setup.hs file, but then we realised that having the package configuration 
> available *as data* gave us a lot more scope for automation, albeit at 
> the expense of some generality.


Note, I wholeheartedly agree with the idea of package configuration as
data. In fact, when cabal first started, I was a huge advocate of it and
in fact _lost interest_ in the project because of the decision to go
with the programatic Setup.hs rather than a declarative approach.

However, I think cabal is a _poor execution_ of the idea. And this
problem is compounded by the fact it is being promoted as the haskell
way to do things, it's design decisions are affecting development and
evolution of the base libraries. And it's monolithic nature and attitude
of wanting to take over your whole projects build cycle means that
alternate approaches cannot be explored.


> That's the tradeoff - but there's still nothing stopping you from using  
> autoconf and your own build system instead if you need to!

But it is a false tradeoff. the only reason one needs to make that
tradeoff is because cabals design doesn't allow the useful ability to
mix-n-match parts of it. I would prefer to see cabal improved so I _can_
use its metadata format, its configuration manager for simple projects,
autoconf's for more complex ones (with full knowledge of the tradeoffs)
and without jumping through hoops.

>> As for programs written in haskell, I don't want people's first
>> impression of haskell being "oh crap, I gotta learn a new way to build
>> things just because this program is written in some odd language called
>> 'haskell'" I don't care how awesome a language is, I am going to be
>> annoyed by having to deal with it when I just want to compile/install a
>> program. It will leave a bad taste in my mouth. I would much rather
>> peoples first impression be "oh wow, this program is pretty sweet. I
>> wonder what it is written in?" hence they all use ./configure && make by
>> design rather than necessity.
>
> Python packages don't have ./configure or make...

Some don't. And it bugs the hell out of me. They don't work with my
autopackaging tools.

>> I sometimes hear that I just shouldn't use cabal for some projects but,
>> when it comes down to it. If cabal is a limited build/configuration
>> system in any way, why would I ever choose it when starting a project
>> when I know it is either putting a limit on my projects ability to
>> innovate or knowing that at some point in the future I am going to have
>> to switch build systems?
>
> Because if you *can* use Cabal, you get a lot of value-adds for free  
> (distro packages, cabal-install, Haddock, source distributions, Hackage). 
> What's more, it's really cheap to use Cabal: a .cabal file is typically  
> less than a screenful, so it's no big deal to switch to something else  
> later if you need to.

except suddenly you can't use hackage and have to come up with a new
build system and perhaps upset my users as they have to learn a new way
to build the project. 

The fact is that it _is_ a big deal to replace cabal is the main issue I
have. switching involves changing your build system completely. you
can't replace just parts of it easily. Or integrate cabal from the
bottom up rather than the top down. And it wants to be the _one true_
build system in your project.

I'd like to see a standardized meta-info format for just haskell
libraries, based on the current cabal format without the cabal specific
build information. (this is what jhc uses, and franchise too I think)
Just like the 'lsm' linux software map files. Preferably YAML, we are
pretty darn close already and it will give us parsers in many languages
for free. We already have several tools that can use the meta-info, jhc,
cabal, franchise, hackage (for the web site layout) so it seems like
abstracting it from the build info would be a useful step in the right
direction.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈