On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote:
> Well, as long as the requirements are expressed in the form,
>
>     "package-name": ">=1.2.3"

This will allow Dub to pick a new major version with incompatible changes, no?

Also, see my reply to Mathias regarding dub.selections.json.

>> No, it is not necessary. The directory layout could be ~/.dub/fruit-1.0.0/fruit/...
>
> I don't follow your point here.  What's the meaningful difference between what dub does and what you suggest?

As I said in my reply to Mathias, what dub does breaks the module path and file path consistency when modules/subpackages lie in the repository root.

On Mon, 02 Feb 2015 10:08:58 +0000, Joseph Rushton Wakeling wrote:

> then there shouldn't be any problem with a version bump from the upstream application.  Whether dub actually does check for updates I'm not sure, but it _could_.  Whereas with git submodules, you really are stuck with one version and one only.

recently ;-) git got a feature "use HEAD for submodule", which removes this limitation.

On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>
> [snip]

I agree with basically everything you said.
I'll add, I have no use for (and no way to use) dub because I depend
on cross-language build configurations.
If my D project depends on a C lib, then what am I supposed to do to
make dub useful for me?

I have an issue with your proposed module management solution that I
wonder if you can address.
You suggest placing source in the root of the repo. Just... no. I will
never do that. The root directory is for readme's, licenses, maybe a
build script. It's not the place for the source, that lives in 'src'.
What's the solution to this problem?
Is it that your src directory should have symlinks to the src
directories of the submodules? Is that why you raise the symlink
support on windows issue? I haven't thought of that before, and have
no idea if it works...

Does git support relative symlinks?

On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
> What's the solution to this problem?

This is a bit of a hack, but so far my solution is to further split up the package's modules to subpackages:

https://github.com/CyberShadow/ae

> Is it that your src directory should have symlinks to the src
> directories of the submodules? Is that why you raise the symlink
> support on windows issue? I haven't thought of that before, and have no idea if it works...

Yes. It would also allow using Deimos repositories with git.

Unfortunately, it doesn't work on Windows.

> Does git support relative symlinks?

I think so - just not on Windows.

On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
> On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>>
>> [snip]
>
> I agree with basically everything you said.
> I'll add, I have no use for (and no way to use) dub because I depend
> on cross-language build configurations.
> If my D project depends on a C lib, then what am I supposed to do to
> make dub useful for me?
>

I don't understand, can't you just use a C build tool for the C lib and link to it via dub?

On Mon, 02 Feb 2015 11:04:29 +0000, Tobias Pankrath wrote:

> On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
>> On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>>>
>>> [snip]
>>
>> I agree with basically everything you said.
>> I'll add, I have no use for (and no way to use) dub because I depend on
>> cross-language build configurations.
>> If my D project depends on a C lib, then what am I supposed to do to
>> make dub useful for me?
>>
>>
> I don't understand, can't you just use a C build tool for the C lib and link to it via dub?

and then we have TWO build tools. and a script that invokes one, and then another. THREE build tools. see the pattern?

On Monday, 2 February 2015 at 10:31:42 UTC, ketmar wrote:
> recently ;-) git got a feature "use HEAD for submodule", which removes this limitation.

Nice!  If you combine that with an upstream that has properly-supported release branches, it's a much better situation.

On Mon, 2015-02-02 at 08:09 +0000, Vladimir Panteleev via Digitalmars-d wrote:
> 
[…]
> 2. git
> 
> I've found that git's submodule feature is an excellent way to manage dependencies across D libraries, and fits really well with D's package system. For clarity to readers not too familiar with Git, I'll explain by example:
> 
> […]

Go allows for Git, Mercurial and Bazaar. This is a good idea since it obviates the "but you are not using the DVCS I want to use" problem.

The problem with Git is versioning. Gradle, Maven, Herd (Ceylon package repository) handle this easily. Go has a real problem with this and Gustavo created a versioning strategy that works well. cf. http://labix.org/gopkg.in

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Unless things have changed significantly or I remember incorrectly, vibe.d depends on C code (libevent), which gets built by dub.

Atila

On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote:
> On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote:
>>
>> [snip]
>
> I agree with basically everything you said.
> I'll add, I have no use for (and no way to use) dub because I depend
> on cross-language build configurations.
> If my D project depends on a C lib, then what am I supposed to do to
> make dub useful for me?
>
> I have an issue with your proposed module management solution that I
> wonder if you can address.
> You suggest placing source in the root of the repo. Just... no. I will
> never do that. The root directory is for readme's, licenses, maybe a
> build script. It's not the place for the source, that lives in 'src'.
> What's the solution to this problem?
> Is it that your src directory should have symlinks to the src
> directories of the submodules? Is that why you raise the symlink
> support on windows issue? I haven't thought of that before, and have
> no idea if it works...
>
> Does git support relative symlinks?

On Monday, 2 February 2015 at 12:54:02 UTC, Atila Neves wrote:
> Unless things have changed significantly or I remember incorrectly, vibe.d depends on C code (libevent), which gets built by dub.

At least for Windows, Vibe includes pre-built libevent binaries (DLL and import library) in the git repository.