View mode: basic / threaded / horizontal-split · Log in · Help
February 17, 2013
Re: The DUB package manager
On 2013-02-17 10:01, Russel Winder wrote:

> Comment from a build veteran last Tuesday: "I will not use any build
> system that cannot be used as a library."
>
> This is the modern way.
>

Agree.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
On 2013-02-16 20:07, Sönke Ludwig wrote:

> I was thinking more along the lines of make, cmake, D based build
> scripts in the form as proposed in the past here and others. Such
> procedural build files often tend to get bloated over time and hard to
> work with. While this is not necessarily a problem with the tools
> itself, it can still make people look for alternatives.
>
> That said, if a scripting language is used (almost) purely to provide a
> declarative system as in your example, it doesn't have to be bad at all.
> The question that arguably remains is just if the added flexibility is
> actually useful or necessary and if such a thing "pulls its own weight"
> (WRT implementation and API complexity).
>

I think so.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
Am 17.02.2013 14:51, schrieb Jacob Carlborg:
> On 2013-02-16 20:07, Sönke Ludwig wrote:
> 
>> I was thinking more along the lines of make, cmake, D based build
>> scripts in the form as proposed in the past here and others. Such
>> procedural build files often tend to get bloated over time and hard to
>> work with. While this is not necessarily a problem with the tools
>> itself, it can still make people look for alternatives.
>>
>> That said, if a scripting language is used (almost) purely to provide a
>> declarative system as in your example, it doesn't have to be bad at all.
>> The question that arguably remains is just if the added flexibility is
>> actually useful or necessary and if such a thing "pulls its own weight"
>> (WRT implementation and API complexity).
>>
> 
> I think so.
> 

Any examples?
February 17, 2013
Re: The DUB package manager
On 2013-02-17 13:58, Sönke Ludwig wrote:

> But that would need to happen as a separate step and then there would be
> two redundant files in the repository, with the usual danger of
> inconsistencies between the two.

The tool generates the JSON/Yaml/XML from the D script. The user never 
have to see the Json file.

> Since a build script may behave differently on different systems, it
> could also happen that the contents cannot really be described as
> JSON/XML. For example someone might get the idea to search the system
> for some library and only add a corresponding dependency if it is found.
> There would be no way for the registry to represent that.

Sure, it's always possible to do stupid things.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
On 2013-02-17 14:40, Nick Sabalausky wrote:

> Plus, some of it's syntax is rather non-intuitive:
>
> !!map {
>    ? !!str "---"
>    : !!str "foo",
>    ? !!str "...",
>    : !!str "bar"
> }
>
> WTF?

I have used Yaml quite a lot but I have never seen that. I think the 
below is very intuitive:

point:
  x: 1
  y: 2

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
On 2013-02-17 14:53, Sönke Ludwig wrote:

> Any examples?

The DWT build script if fairly complex:

D: https://github.com/d-widget-toolkit/dwt/blob/master/build.d
Rakefile: https://github.com/d-widget-toolkit/dwt/blob/master/rakefile

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
Am 17.02.2013 15:09, schrieb Jacob Carlborg:
> On 2013-02-17 14:53, Sönke Ludwig wrote:
> 
>> Any examples?
> 
> The DWT build script if fairly complex:
> 
> D: https://github.com/d-widget-toolkit/dwt/blob/master/build.d
> Rakefile: https://github.com/d-widget-toolkit/dwt/blob/master/rakefile
> 

I see some things like windows/non-windows specific flags and a lot of
path handling and infrastructure stuff (which the build tool would do
itself). Anything in particular that you think is not easily doable with
the data driven approach?

BTW, I think build files like these are the perfect example for what I
mean with complexity and scaring away people. I'm sure it all makes
sense, but my vision of a build system is that it goes out of the
developers way instead of forcing him to maintain a whole sister project
alongside the actual code.
February 17, 2013
Re: The DUB package manager
Am 17.02.2013 15:04, schrieb Jacob Carlborg:
> On 2013-02-17 13:58, Sönke Ludwig wrote:
> 
>> But that would need to happen as a separate step and then there would be
>> two redundant files in the repository, with the usual danger of
>> inconsistencies between the two.
> 
> The tool generates the JSON/Yaml/XML from the D script. The user never
> have to see the Json file.
> 

But the registry gets its information about a package directly from the
github repository (this is quite a central idea), so it must also be
committed there.

>> Since a build script may behave differently on different systems, it
>> could also happen that the contents cannot really be described as
>> JSON/XML. For example someone might get the idea to search the system
>> for some library and only add a corresponding dependency if it is found.
>> There would be no way for the registry to represent that.
> 
> Sure, it's always possible to do stupid things.
> 

But at least not this particular this with the data driven approach ;)
February 17, 2013
Re: The DUB package manager
Don't really have a vision how it will look like in practice 
based on released data, but looking at current discussion I'd 
like to state that I am most interested in a centralized 
library/app list, dependency tracker and an easy way to get 
sources. Support for a popular build systems may be fine as a 
bonus, but only as an added feature, with no coupling. I'd hate 
to see a ruby gem (or similar) hell pushed as a "D way". 
Packaging is best done (and should be) by OS package manager, not 
hundreds of languages-specific managers. Good language package 
manager in my opinion is just an information source for OS 
package builders.
February 17, 2013
Re: The DUB package manager
On 2013-02-17 15:32, Sönke Ludwig wrote:

> But the registry gets its information about a package directly from the
> github repository (this is quite a central idea), so it must also be
> committed there.

Aha, that would be a problem. With Orbit you build a package out of an 
orbspec (the DSL) and the package will contain the meta info.

-- 
/Jacob Carlborg
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home