View mode: basic / threaded / horizontal-split · Log in · Help
February 23, 2013
Re: The DUB package manager
On Sunday, 17 February 2013 at 11:20:55 UTC, Sönke Ludwig wrote:

> My question if we can get by without procedural build scripts 
> is still
> open. If we could, it would give great benefits in simplicity 
> of the
> system and its usage. This may require a change in conventions 
> for some
> projects, but I think that can be worth it.
>
> Maybe it would be good to have some concrete examples of 
> complex build
> scenarios to better judge what is possible and what may be 
> problematic.



I think embedding procedural scripts are always a plus. Given 
that you already have JSON, I would vote for *cough* Javascript 
(V8 engine).
February 23, 2013
Re: The DUB package manager
Am 22.02.2013 14:31, schrieb Moritz Maxeiner:
> On Friday, 22 February 2013 at 11:01:12 UTC, Sönke Ludwig wrote:
>>
>> Thanks! I've listed it on the github page:
>> https://github.com/rejectedsoftware/dub#arch-linux
>>
>> BTW, the build process has been simplified now - dependencies are just
>> DMD+libcurl and building works using "./build.sh" instead of using
>> "vibe build".
> 
> Thanks for the news, I've updated both packages with the correct
> dependencies and bumped the release to 0.9.7.
> Btw. is there some way in Github to be notified (only) about new tags of
> a project (So I can update the AUR release package asap)?

I think there is none, just a commit feed that doesn't include tags. But
once I have set up automatic builds, I could add a small script that
makes a notification or simply uploads the new package file.
February 23, 2013
Re: The DUB package manager
Am 23.02.2013 10:20, schrieb SomeDude:
> On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig wrote:
>> To me the most interesting open question is this: Do we actually gain
>> from programmatic support for the build description, or does it suffice
>> to have a good purely descriptive system? If the former should be true
>> for more than 1% of the cases, that would definitely be a good argument
>> against pure data.
> 
> Well, in the Java world, there is ant. It does the trick, but it's quite
> ugly.

And it also does the really strange thing to actually build up a
procedural build description in a declarative (+ugly) language. That's
definitely not what I have in mind - what I want is really a pure
/description/ of the system, from which the build steps (or anything
else) can be inferred.

This has the big advantage that you can decouple the two concepts and do
generic things with all packages, even if the package maintainer didn't
explicitly write supporting code (e.g. generate documentation, generate
a project file, generate an installer, build as a DLL etc.).

The question is if we need procedural statements to create that package
description or not. So far I haven't really seen a compelling example
that we do. And staying with a declarative approach has the advantage
that the language is _not_ more powerful than the thing that it is
supposed to model, i.e. no information is lost.

An example where it is easy to mess up with a procedural language and
not have a real package description anymore is if the user uses the
scripting language to make decisions based on outside conditions (OS,
architecture, installed libraries, time of day, whatever). The result is
a description that is not really a description of the package anymore,
but of the package+environment, which makes it unpredictable and thus
impossible to safely make decisions about other environments (build
servers, cross compilation, platform independent list of dependencies
etc. pp.).
February 23, 2013
Re: The DUB package manager
Am 23.02.2013 10:24, schrieb SomeDude:
> On Sunday, 17 February 2013 at 11:20:55 UTC, Sönke Ludwig wrote:
> 
>> My question if we can get by without procedural build scripts is still
>> open. If we could, it would give great benefits in simplicity of the
>> system and its usage. This may require a change in conventions for some
>> projects, but I think that can be worth it.
>>
>> Maybe it would be good to have some concrete examples of complex build
>> scenarios to better judge what is possible and what may be problematic.
> 
> 
> 
> I think embedding procedural scripts are always a plus. Given that you
> already have JSON, I would vote for *cough* Javascript (V8 engine).

If anything, DMDScript, of course ;)

(WRT procedural, I still think that non-procedural might actually be
better in this case, see prev. reply)
February 23, 2013
Re: The DUB package manager
On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
[…]
> Well, in the Java world, there is ant. It does the trick, but 
> it's quite ugly.

Anyone in the Java world still using Ant is just so last decade ;-)

Maven attempts to be wholly declarative and succeeds in that all the
hard work is done via plugins coded in Java or Groovy code.

Gradle makes no pretence as being either declarative or iterative, but
embraces both. As much of a specification is as declarative as possible,
but where imperative is needed it is available as Gradle specifications
are Groovy scripts with the Gradle internal DSL.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
February 23, 2013
Re: The DUB package manager
On Saturday, 23 February 2013 at 10:21:59 UTC, Sönke Ludwig wrote:
> Am 23.02.2013 10:20, schrieb SomeDude:
>> On Sunday, 17 February 2013 at 08:02:41 UTC, Sönke Ludwig 
>> wrote:
>>> To me the most interesting open question is this: Do we 
>>> actually gain
>>> from programmatic support for the build description, or does 
>>> it suffice
>>> to have a good purely descriptive system? If the former 
>>> should be true
>>> for more than 1% of the cases, that would definitely be a 
>>> good argument
>>> against pure data.
>> 
>> Well, in the Java world, there is ant. It does the trick, but 
>> it's quite
>> ugly.
>
> And it also does the really strange thing to actually build up a
> procedural build description in a declarative (+ugly) language. 
> That's
> definitely not what I have in mind - what I want is really a 
> pure
> /description/ of the system, from which the build steps (or 
> anything
> else) can be inferred.
>

In my experience, this ends up with an explosion of plugins or 
special cases to handle some tricks in the build. At the end, you 
ends up having some kind of programming language, but horribly 
designed.

I don't think both contradict themselves, as you can provide 
descriptive definition via several declaration with known names. 
You can also provide hooks or way to create plugins from withing 
the script definition. That were they belongs if you don't want 
user to download 10 bazillions plugins in addition to the build 
system.
February 23, 2013
Re: The DUB package manager
On Saturday, 23 February 2013 at 11:21:06 UTC, Russel Winder 
wrote:
> On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
> […]
>> Well, in the Java world, there is ant. It does the trick, but 
>> it's quite ugly.
>
> Anyone in the Java world still using Ant is just so last decade 
> ;-)
>
> Maven attempts to be wholly declarative and succeeds in that 
> all the
> hard work is done via plugins coded in Java or Groovy code.
>

Comparing ant and maven is not appropriate here as maven is a 
build system + a package manager when ant only builds.

The plugin system of maven is notoriously hellish. This shows 2 
things :
1/ That extending the build system is really required, and if not 
permitted from the build file themselves, by plugins to extends 
the descriptive capabilities of the descriptive language.
3/ That the benefice of having the build tool and the package 
manager working together is big as people plebiscite it even when 
the system is way worse on many other aspects.
February 23, 2013
Re: The DUB package manager
On Saturday, 23 February 2013 at 11:21:06 UTC, Russel Winder 
wrote:
> Gradle makes no pretence as being either declarative or 
> iterative, but
> embraces both. As much of a specification is as declarative as 
> possible,
> but where imperative is needed it is available as Gradle 
> specifications
> are Groovy scripts with the Gradle internal DSL.
> 

Do you have some link I can read about this ? This sounds like a 
very nice project !
February 23, 2013
Re: The DUB package manager
On Friday, 22 February 2013 at 20:33:15 UTC, Jonathan M Davis 
wrote:
> On Friday, February 22, 2013 19:29:02 deadalnix wrote:
>> So I'm sorry if that appears completely stupid, but . . .
>> 
>> DUB sounds kind of like dumb. As Orbit sounds very nice,
>> especially since libraries are satellites of mars, so it make
>> sense to see other libs as artificial satellites :D
>> 
>> That is very poor, and have nothing to do with the actual
>> capabilities of each of them.
>
> Really? I see no problem with either, and if anything, I like 
> dub better
> because it's shorter (it also starts with d). I don't feel 
> particularly
> strongly either way though.
>
> - Jonathan M Davis

I sense deadalnix attempted yet again at being 
sarcastic/humorous, and failed at it. Again. :)
February 23, 2013
Re: The DUB package manager
On Sat, 23 Feb 2013 11:20:50 +0000
Russel Winder <russel@winder.org.uk> wrote:

> On Sat, 2013-02-23 at 10:20 +0100, SomeDude wrote:
> […]
> > Well, in the Java world, there is ant. It does the trick, but 
> > it's quite ugly.
> 
> Anyone in the Java world still using Ant is just so last decade ;-)
> 

Anyone still using Java is just so last decade ;)
10 11 12 13 14 15 16 17 18
Top | Discussion index | About this forum | D home