Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tim Cuthbertson <tim <at> gfxmonk.net>
Subject: Re: progress on distributing haskell libraries / programs with zero install
Newsgroups: gmane.comp.file-systems.zero-install.devel
Date: Sunday 5th August 2012 00:03:07 UTC (over 5 years ago)
I've now got a working implementation for a
less-efficient-but-more-correct way of distributing haskell libraries
(when compared to my previous efforts:
http://sourceforge.net/mailarchive/message.php?msg_id=29351261).
The
basic idea is that we distribute *only* source implementations of
libraries, and binaries are either statically compiled or include the
.so files for their dependencies within their implementation. I'm
fully aware that this is not great for sharing compiled code and
prevents upgrading dependencies without recompiling the program, but
this is not an easy problem to solve for haskell, and I'd rather have
something that works than nothing (distros only manage to distribute
binary libraries because they have the ability to trigger a full
recompile whenever the version of GHC changes, which we can't).

When it comes time to compiling, my cabal-build script will use
$CABAL_PKG_PATH (which I made up) to populate a directory in $BUILDDIR
that looks a lot like a hacakge cache (hackage is the online
repository for haskell, like rubygems / CPAN / pypi), but happens to
have exactly the dependencies that zeroinstall has resolved. It then
just runs `cabal install`, which typically will download dependencies
as needed from hackage - but here we force it to use *only* the local
cache directory, ensuring that it uses the exact dependencies that
it's supposed to and no more.

There's a few wrinkles with this plan. Libraries look kind of odd. For
now I've made a haskell-ansi-terminal-dev.xml feed which contains the
haskell source code for this library, marked as arch="*-*". There is
no haskell-ansi-terminal.xml in this setup, only a -dev feed. The
 step of my program then depends on
haskell-ansi-terminal-dev.xml, and uses my custom cabal-build program
from above to ensure that the source gets used. This also means that a
feed could not be both a library and a program (e.g if there were some
executable in it, but that it also exported haskell modules for other
programs to use). Obviously we need to compile a program before we
could use it, but we specifically want to avoid using a pre-compiled
library.

I think this could work much better though, if 0compile / 0install
could be extended to allow the following:

 - haskell-ansi-terminal.xml exports its source implementation as
arch="*-src"
 - haskell-snip.xml (my program) includes 

That way, even if haskell-ansi-terminal.xml had a runnable binary
implementation, 0compile would still only look for a src
implementation, as that's the only reliable way to build
haskell-snip.xml
Also, 0compile would probably need to be modified to not complain in
this case if the src implementation of haskell-ansi-terminal.xml has
no compile command. With analogy to a non-runnable (library) feed,
it's a non-compileable source feed that can only be used when
compiling *other* software.

Does this sound reasonable / possible to implement? Is there anything
else it might break?

Would 0compile be able to (and know to) recompile a new version of
snip (the program) if its version does not change but one of its src
dependencies does? I think this is something that should be supported
in general, but I'm not sure if 0compile currently allows another
implementation to be generated for the same feed+version. I still
really think we ought to support 0compiling feeds automatically if
there's a newer source version, but that's another thread ;)

Cheers,
 - Tim.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 
CD: 3ms