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