View mode: basic / threaded / horizontal-split · Log in · Help
February 17, 2013
Re: The DUB package manager
On 2013-02-17 09:02, Sönke Ludwig wrote:

> But you will have to learn the API of the build script helpers, too. I'm
> not sure if this is actually less to learn than the JSON alternative.

You still have to learn this:

http://registry.vibed.org/package-format

>   - Meta information needs to be available to the package registry and
> for managing dependencies in general. Executing a script/program would
> imply a big performance risk, and worse, is a high security risk in case
> of the registry. So a data-driven approach is needed at least for the
> meta data anyway.

You can just serialize the D data structure to XML/JSON to make it safe 
for the registry.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
On 2013-02-16 20:37, H. S. Teoh wrote:

> I think Sönke's idea is actually very good. I know we all have our own
> preferences for build systems (I know I do -- for example, I abhor
> anything to do with makefiles), but having a standardized way to specify
> a build has many advantages. Imagine the user-unfriendliness of
> downloading a bunch of packages from the D package manager, only to
> discover that one requires make, another requires cmake, another
> requires SCons, another requires Ant, pretty soon, what should be just a
> simple automatic download turns into a nightmare of installing 20
> different build systems just so you can use a bunch of packages from the
> standard D package manager.
>
> Having a standardized way of generating build scripts is good, because
> then the D package manager can target the *end user*'s preferred build
> system, rather than whatever build system the package writers chose. The
> package writers can just specify how to build the stuff, then let the D
> packager generate makefiles for one user, Ant files for another user,
> etc.. This makes it much more friendly to use, and therefore, more
> likely people will actually use it.

The build system doesn't need to embedded in the package manager just to 
have a standardize build system. See this:

http://forum.dlang.org/thread/kfoei9$bmd$1@digitalmars.com?page=4#post-kfqium:24unf:241:40digitalmars.com

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
Am 17.02.2013 13:47, schrieb Jacob Carlborg:
> On 2013-02-17 09:02, Sönke Ludwig wrote:
> 
>> But you will have to learn the API of the build script helpers, too. I'm
>> not sure if this is actually less to learn than the JSON alternative.
> 
> You still have to learn this:
> 
> http://registry.vibed.org/package-format
> 

Yes, I meant that with the JSON alternative. JSON itself is so simple
and widely known, that I think it can be neglected compared to the
possible fields.

>>   - Meta information needs to be available to the package registry and
>> for managing dependencies in general. Executing a script/program would
>> imply a big performance risk, and worse, is a high security risk in case
>> of the registry. So a data-driven approach is needed at least for the
>> meta data anyway.
> 
> You can just serialize the D data structure to XML/JSON to make it safe
> for the registry.
> 

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.

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.
February 17, 2013
Re: The DUB package manager
On 2013-02-16 21:02, Johannes Pfau wrote:

> Having a common standard build tool is always good. But some kind of
> projects require custom build scripts (calling swig, generating
> interface files for ipc stuff, executing the C compiler to check if a
> function is available to disable / enable additional features, calling
> pkgconfig for some reason, compiling additional c/c++ files, assembling
> additional files, ...).
>
>
> I think splitting DUB into a package manger and build tool would be a
> good idea. Ship them as one package, so that everyone using the package
> manager also has the build tool installed. And integrate them as much
> as possible, the default setup can still work exactly the same as if
> they were integrated.
>
> The benefit of splitting them in this way: You're forced to provide
> interfaces for the build tool to communicate with the package manager
> and every other build tool can use those interfaces as well. This way
> there are no second class build systems.
>
> As an example:
>
> package.json
> {
> 	"name": "myproject",
> 	"description": "A little web service of mine.",
> 	"authors": ["Peter Parker"],
> 	"homepage": "http://myproject.com",
> 	"license": "GPL v2",
> 	"dependencies": {
> 		"vibe-d": ">=0.7.11"
> 	},
>          "build": "DUB"
> }
>
> build.json
> {
> 	"configurations": {
> 		"metro-app": {
> 			"versions": ["MetroApp"],
> 			"libs": ["d3d11"]
> 		},
> 		"desktop-app": {
> 			"versions": ["DesktopApp"],
> 			"libs": ["d3d9"]
> 		}
> 	}
> }
>
> doing a "dub-pkg install myproject" should fetch the sources, then call
> "dub-build build.json". dub-build will have to ask the package manager
> for some information: "dub-pkg package.json --query dependencies",
> "dub-pkg package.json --query --package=vibe.d --link-path". Or it
> might require some additional actions: "dup-pkg --install-dependency
> d3d9"
>

Exactly. But I see no reason for communicating with processes. Just make 
them both into libraries and call functions plain functions.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
On 2013-02-16 23:19, Peter Sommerfeld wrote:

> Another issue: I understand why you are using json but it is
> not the best suited format IMHO. D put some restriction on
> module names, thus the format can be simplified. Compare:

Inventing a new format is pointless. I you want it less verbose Yaml is 
an alternative.

-- 
/Jacob Carlborg
February 17, 2013
Re: The DUB package manager
Am 17.02.2013, 14:03 Uhr schrieb Jacob Carlborg:

> On 2013-02-16 23:19, Peter Sommerfeld wrote:
>
>> Another issue: I understand why you are using json but it is
>> not the best suited format IMHO. D put some restriction on
>> module names, thus the format can be simplified. Compare:
>
> Inventing a new format is pointless. I you want it less verboseYaml is  
> an alternative.

If you prefer indentation. I would never touch it.

Peter
February 17, 2013
Re: The DUB package manager
Am 17.02.2013, 11:58 Uhr, schrieb Sönke Ludwig:
> Am 17.02.2013 11:21, schrieb Peter Sommerfeld:
> Not sure what you mean by project manager, but right now, I see no
> reason why it shouldn't be possible to keep the package/build
> description very compact.

If a good configuration format for D is established, it will (or
should) be used everywhere.

>> Regarding json: It is designed ...
> This is just wrong. JSON is just JavaScript, which is meant for human
> editing just as D or a custom DSL is.

OK, that is not important. The point is: Config files have to
be edited by humans and all the quotes are simply superfluous,
annoying and error-prone.

The appropriate file format has low-priority and may be discussed
when a general decision about using dub as build-tool has been
made. I am for it! So let us continue with more important issues
for now.

Peter
February 17, 2013
Re: The DUB package manager
Am 17.02.2013, 11:58 Uhr, schrieb Sönke Ludwig:
> Am 17.02.2013 11:21, schrieb Peter Sommerfeld:
> Not sure what you mean by project manager, but right now, I see no
> reason why it shouldn't be possible to keep the package/build
> description very compact.

If a good configuration format for D is established, it will (or
should) be used everywhere.

>> Regarding json: It is designed ...
> This is just wrong. JSON is just JavaScript, which is meant for human
> editing just as D or a custom DSL is.

OK, that is not important. The point is: Config files have to
be edited by humans and all the quotes are simply superfluous,
annoying and error-prone.

The appropriate file format has low-priority and may be discussed
when a general decision about using dub as build-tool has been
made. I am for it! So let us continue with more important issues
for now.

Peter
February 17, 2013
Re: The DUB package manager
On Sun, 17 Feb 2013 14:28:14 +0100
"Peter Sommerfeld" <noreply@rubrica.at> wrote:

> Am 17.02.2013, 14:03 Uhr schrieb Jacob Carlborg:
> 
> > On 2013-02-16 23:19, Peter Sommerfeld wrote:
> >
> >> Another issue: I understand why you are using json but it is
> >> not the best suited format IMHO. D put some restriction on
> >> module names, thus the format can be simplified. Compare:
> >
> > Inventing a new format is pointless. I you want it less verboseYaml
> > is an alternative.
> 
> If you prefer indentation. I would never touch it.
> 

Plus, some of it's syntax is rather non-intuitive:

!!map {
 ? !!str "---"
 : !!str "foo",
 ? !!str "...",
 : !!str "bar"
}

WTF?
February 17, 2013
Re: The DUB package manager
On 2013-02-17 10:24, Russel Winder wrote:
> On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote:
>
>> I agree about the non-optimal syntax, but it comes down to nicer syntax
>> (where JSON at least is not _too_ bad) vs. standard format (familiarity,
>> data exchange, proven design and implementation). And while data
>> exchange could worked around with export/import functions, considering
>> that these files are usually just 4 to 20 lines long, I personally would
>> put less weight on the syntax issue than on the others.
>>
>> BTW, I think YAML as a superset of JSON is also a good contender with
>> nice syntax features, but also much more complex.
>
> Peter's point is more important than the above response indicates.
>
> Using JSON (YAML, whatever) is a recipe for failure. The syntax is data
> exchange facing, whereas writing and maintaining a build script (even if
> it is only 4 lines long), is a human activity. Do not underestimate the
> reaction "why do I have to write this data exchange format?" The rapid
> demise of XML, Ant, Maven, etc. is testament to people awakening to the
> fact that they were forced to use manually a language designed for
> another purpose.
>
> Where Gradle, and before it Gant, Buildr, etc., got it right was to use
> an internal DSL mentality to ask what is a written form that has
> affordance for the user that we can interpret in some way to deliver for
> computation the data needed. Groovy provides the infrastructure for
> Gradle, but people write Gradle scripts not Groovy. The build/packaging
> system does the hard work, not the user.
>
> The lesson from SBT is that by judicious cleverness, a trivially simple
> internal DSL can be derived that does all the work using Scala. The only
> downside to SBT scripts is the extra newline needed everywhere. Surely D
> is better than Scala for this?

Unfortunately I don't think D is better than Scala. I would say that you 
can do everything/most that Scala/Groovy can but not with as nice syntax 
as Scala/Groovy.

> So if D is to contribute to build and package management, it should be
> looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to
> build D systems yes, and manage D packages, but also look to build C, C
> ++, Fortran, and interlink all of them. Clearly starting small is good:
> a successful large system always evolves from a successful small system;
> designed large systems always fail. (cf. Gall, Systemantics, 1975)

I don't think it necessarily needs to be able to build non-D projects. 
I'm looking at Gradle now. The first example they show is this:

task hello {
    doLast {
        println 'Hello world!'
    }
}

That translated to D would probably look something like this:

task("hello", {
    doLast({
        writeln("Hello World");
    });
});

Which in my opinion is a lot uglier the the original Groovy code. A 
couple of problems with D:

* Semicolons
* Parentheses when making function calls
* No block syntax. Not possible to pass a delegate after the regular 
arguments

> If all the energy around DUB and Orbit leads to the situation where D
> cannot be used to create an internal DSL for describing build and
> package/artefact management, then D has failed.

As I've said. I will change Orbit to use D for the DSL.

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