Re: Version control systems

[Hisham <hisham.hm@...>]

On Tue, Aug 12, 2008 at 11:30 PM, Asko Kauppi <askok@dnainternet.net> wrote:
>
> That's a refreshing point of view, and you might be right.

The flaw in the argument is to assume that the native packaging
systems are all functionally equivalent and that providing an
interface for them is a sufficient solution for the packaging needs of
a dynamic language. LuaRocks works in a way that rpm/deb/etc. can't:
it resolves dependency versions at require() time, and is designed to
allow multiple coexisting versions of packages transparently. Having
said that, nothing prevents from using LuaRocks as a build tool with
the end goal of producing platform-specific packages -- in fact, there
has been talk about this in the LuaRocks mailing list, and I find it
an excellent route for packagers who wish to provide native packages.
Some of the flexibility that LuaRocks provides, however, is lost, but
it may not be a problem for them, since it's a kind of flexibility
that is not present in their packaging systems to start with. On the
other hand, for those who need this flexibility, LuaRocks has proven
to be a valuable tool, so dismissing it as a bad idea or unnecessary
diversity is, in my opinion, premature judgement.

-- Hisham

> Norman Ramsey kirjoitti 12.8.2008 kello 21:55:
>
>>>> I see an increasing problem in that every community comes up with
>>>> their own package system, instead of reusing existing frameworks.
>>>
>>> That's because there are no usable existing frameworks.
>>
>> I couldn't agree more.  I have been working on this problem off and on
>> since 1993, and the situation now is even worse than it was then.
>> It's become a full-time job just to keep track of the frameworks.
>> (For example, I'm not as informed about Omake as I'd like to be.)
>>
>> As someone who hangs out in a bunch of different language communities,
>> I see two needs driving unnecessary diversity in build/package systems:
>>
>>  1. Language implementors see that they are serving multiple
>>    platforms (debian, red hat, bsd, windows, macos, ...), each of
>>    which has its own native packaging system, with its own way of
>>    expressing dependencies.  The bad idea: invent a new system which
>>    works across all these platforms but serves only one language.
>>    This path was the genesis of 'Lua rocks', for example.  And
>>    although I can't speak of Ruby and Java of my own knowledge, I
>>    suspect that Ruby gems and Java beans are similar.  I don't
>>    really understand Cabal, but to the degree that I do, Cabal fills
>>    a similar role for Haskell.
>>
>>  2. The technique of 'smart recompilation', described in a 1986
>>    journal article by Walter Tichy (who also invented RCS), has
>>    (again to my knowledge) has been reinvented again and again for
>>    one language after another---it has *never* been packaged as a
>>    reusable framework.  I know of two valiant efforts: Clemm and
>>    Osterweil's "Odin" build tool and Blume and Appel's Compilation
>>    Manager.  But the Odin people never really had a
>>    programming-language background, and Geoff Clemm was the only one
>>    who could extend the system.  And the Compilation Manager, while
>>    really interesting, didn't make it obvious how to use with
>>    another compiler---in fact I'm not sure if the hooks to support
>>    smart recompilation were even exported.
>>
>> I also see repeatedly that the distinction between the build system
>> and packaging system is blurry: both have to know about build targets,
>> dependencies, and so on.
>>
>> At the time of the wonderful GHC Hackathon in Portland, where the GHC
>> API was first introduced to the public, I urged Simon PJ to consider
>> taking ghc --make and generalising it to support other languages.
>> I still think this would be a good project.
>>
>>> There are tools to convert Cabal packages to native packages for rpm,
>>> deb, ebuild and arch. The Cabal format was designed to allow this
>>> translation. This includes dependencies on C libs and external programs.
>>
>> I think this is an essential property for any language-dependent
>> packaging system to be successful.  I think this is a very good path
>> for Haskell, even though Cabal is a work in progress.  What I like is
>> that it overcomes an impedance mismatch:
>>
>>  * The developer of a Haskell package is presented with *one*
>>   packaging interface (Cabal), which will create a package native to
>>   any widely used platform.
>>
>>  * The client of a Haskell package treats it like any other native
>>   package: rpm, apt-get, emerge, or InstallShield just
>>   *work*---Haskell programs are not marginalized.
>>
>> Of course this model puts a heavy weight on the shoulders of the Cabal
>> team, but given the current state of play, I don't see how it is
>> possible to do better for developers and users.  It's certainly better
>> than the 'Lua rocks' model, which requires the end user to run both
>> the platform-native packaging system *and* the Lua rocks packaging
>> system.  Such an outcome for Haskell is to be avoided at all costs.
>>
>>
>>
>> Norman
>
>