On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote:

> On 30/03/2015 6:35 p.m., ketmar wrote:
>> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>>
>>> Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses.
>>
>> O_O
> 
> Hey hey hey, context matters!

i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here.

and i definetely want to see "std.license.compare" in Phobos! ;-)

On 30/03/2015 7:14 p.m., ketmar wrote:
> On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote:
>
>> On 30/03/2015 6:35 p.m., ketmar wrote:
>>> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>>>
>>>> Although I'm a little concerned because dub is meant to validate and
>>>> tell you conflicts in licenses.
>>>
>>> O_O
>>
>> Hey hey hey, context matters!
>
> i'm speechless 'cause it's a great idea (let machine do it work!), but i'm
> not sure how this can be done with wide broad of licenses out here.
>
> and i definetely want to see "std.license.compare" in Phobos! ;-)

I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have.

On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote:

> On 30/03/2015 7:14 p.m., ketmar wrote:
>> On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote:
>>
>>> On 30/03/2015 6:35 p.m., ketmar wrote:
>>>> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>>>>
>>>>> Although I'm a little concerned because dub is meant to validate and tell you conflicts in licenses.
>>>>
>>>> O_O
>>>
>>> Hey hey hey, context matters!
>>
>> i'm speechless 'cause it's a great idea (let machine do it work!), but i'm not sure how this can be done with wide broad of licenses out here.
>>
>> and i definetely want to see "std.license.compare" in Phobos! ;-)
> 
> I agree, I'm concerned about this as well. But hey, its one of the features the dub developers want to have.

what i really want to have is "libdub". i.e. turning dub to library, so it can be easily integrated in any D project (rdmd comes to mind first). i don't want D building abilities, for example, but i really like to use it's package management part (and get list of files and compiler flags for that packages).

sure, i can do this by parsing dub jsons and execing dub itself to do package management work, but libdub is better...

maybe someday i'll wrote such thing. ;-)

On 30/03/2015 7:26 p.m., ketmar wrote:
> On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote:
>
>> On 30/03/2015 7:14 p.m., ketmar wrote:
>>> On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote:
>>>
>>>> On 30/03/2015 6:35 p.m., ketmar wrote:
>>>>> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>>>>>
>>>>>> Although I'm a little concerned because dub is meant to validate and
>>>>>> tell you conflicts in licenses.
>>>>>
>>>>> O_O
>>>>
>>>> Hey hey hey, context matters!
>>>
>>> i'm speechless 'cause it's a great idea (let machine do it work!), but
>>> i'm not sure how this can be done with wide broad of licenses out here.
>>>
>>> and i definetely want to see "std.license.compare" in Phobos! ;-)
>>
>> I agree, I'm concerned about this as well. But hey, its one of the
>> features the dub developers want to have.
>
> what i really want to have is "libdub". i.e. turning dub to library, so
> it can be easily integrated in any D project (rdmd comes to mind first).
> i don't want D building abilities, for example, but i really like to use
> it's package management part (and get list of files and compiler flags
> for that packages).
>
> sure, i can do this by parsing dub jsons and execing dub itself to do
> package management work, but libdub is better...
>
> maybe someday i'll wrote such thing. ;-)

Yeah, the vibe.d/dub guys are amazing at getting stuff working. But horrible at abstraction's especially with library code.

On Monday, 30 March 2015 at 06:26:00 UTC, ketmar wrote:
> On Mon, 30 Mar 2015 19:17:35 +1300, Rikki Cattermole wrote:
>
>> On 30/03/2015 7:14 p.m., ketmar wrote:
>>> On Mon, 30 Mar 2015 18:54:42 +1300, Rikki Cattermole wrote:
>>>
>>>> On 30/03/2015 6:35 p.m., ketmar wrote:
>>>>> On Mon, 30 Mar 2015 18:23:11 +1300, Rikki Cattermole wrote:
>>>>>
>>>>>> Although I'm a little concerned because dub is meant to validate and
>>>>>> tell you conflicts in licenses.
>>>>>
>>>>> O_O
>>>>
>>>> Hey hey hey, context matters!
>>>
>>> i'm speechless 'cause it's a great idea (let machine do it work!), but
>>> i'm not sure how this can be done with wide broad of licenses out here.
>>>
>>> and i definetely want to see "std.license.compare" in Phobos! ;-)
>> 
>> I agree, I'm concerned about this as well. But hey, its one of the
>> features the dub developers want to have.
>
> what i really want to have is "libdub". i.e. turning dub to library, so
> it can be easily integrated in any D project (rdmd comes to mind first).
> i don't want D building abilities, for example, but i really like to use
> it's package management part (and get list of files and compiler flags
> for that packages).
>
> sure, i can do this by parsing dub jsons and execing dub itself to do
> package management work, but libdub is better...
>
> maybe someday i'll wrote such thing. ;-)

+1

E.g. using libdub in my project DlangIDE would be much easy than command line interface.

Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:
> On 30/03/2015 7:26 p.m., ketmar wrote:
>>
>> what i really want to have is "libdub". i.e. turning dub to library, so
>> it can be easily integrated in any D project (rdmd comes to mind first).
>> i don't want D building abilities, for example, but i really like to use
>> it's package management part (and get list of files and compiler flags
>> for that packages).
>>
>> sure, i can do this by parsing dub jsons and execing dub itself to do
>> package management work, but libdub is better...
>>
>> maybe someday i'll wrote such thing. ;-)

You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time.

>
> Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
> horrible at abstraction's especially with library code.
>

Okay.

On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote:

> You can actually use DUB as a library without any issues (within the DUB eco system, just add it as a dependency, otherwise drop the app.d file when building). The API is still not ideal (missing some documentation and needs some cleanup), because it has grown by contribution from multiple people and a public API hasn't been a primary goal at the time.

i have concerns about API stability, though. it's always better to have "officially announced" library with some guarantees ("we will break API on each release" is good too ;-).

On 1/04/2015 10:28 p.m., Sönke Ludwig wrote:
> Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:

snip

>> Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
>> horrible at abstraction's especially with library code.
>>
>
> Okay.

Nobody can be the best at everything. So it was a compliment :)
You've done an excellent job with them.
And by the looks of things, you are now splitting up e.g. vibe.d So again its mostly past tense observation on that front.

I'm kinda the opposite. Great at abstractions. Horrible at getting the damn thing working.

Am 01.04.2015 um 11:32 schrieb ketmar:
> On Wed, 01 Apr 2015 11:28:12 +0200, Sönke Ludwig wrote:
>
>> You can actually use DUB as a library without any issues (within the DUB
>> eco system, just add it as a dependency, otherwise drop the app.d file
>> when building). The API is still not ideal (missing some documentation
>> and needs some cleanup), because it has grown by contribution from
>> multiple people and a public API hasn't been a primary goal at the time.
>
> i have concerns about API stability, though. it's always better to have
> "officially announced" library with some guarantees ("we will break API
> on each release" is good too ;-).
>

This will happen soon, when it's ready for the 1.0.0 release. It'll then be subject to the usual SemVer guarantees.

Am 01.04.2015 um 11:33 schrieb Rikki Cattermole:
> On 1/04/2015 10:28 p.m., Sönke Ludwig wrote:
>> Am 30.03.2015 um 08:34 schrieb Rikki Cattermole:
>
> snip
>
>>> Yeah, the vibe.d/dub guys are amazing at getting stuff working. But
>>> horrible at abstraction's especially with library code.
>>>
>>
>> Okay.
>
> Nobody can be the best at everything. So it was a compliment :)
> You've done an excellent job with them.
> And by the looks of things, you are now splitting up e.g. vibe.d So
> again its mostly past tense observation on that front.
>
> I'm kinda the opposite. Great at abstractions. Horrible at getting the
> damn thing working.

I personally usually stay away from using overly strong terms like "horrible" for online conversations, because it's just far too likely that someone gets offended (I'm usually a fan of good irony for example, but almost never use it online).

On topic, I don't think that splitting up the library or not does necessarily have anything to do with abstraction. The library is built in a modular way, so that splitting it up mainly just becomes an issue of the build configuration. If you have other examples of where you think the abstractions are lacking, I'd be interested to know of course.

I generally value good abstraction as important, but that doesn't always mean that the most extreme abstraction is the best one. Abstraction comes at the cost of added complexity (on the library side, but more importantly on the user side) and sometimes at the cost of performance, so it's always a trade-off.