February 17, 2013 Re: The DUB package manager | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Sommerfeld | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Sommerfeld | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 |
Copyright © 1999-2021 by the D Language Foundation