Am 01.06.2015 um 08:35 schrieb Nick Sabalausky:
> On 05/31/2015 07:01 PM, Andrei Alexandrescu wrote:
>> Let's make this part of 2.068:
>>
>> https://issues.dlang.org/show_bug.cgi?id=14636
>>
>> It's preapproved. Who would want to work on it?
>>
>
> IIRC, I think Sonke wanted to hold off on that until a dub 1.0. I'm not
> certain exactly what work he had in mind for that though, versus post-1.0.
>

We have collected some things that would be good to have done. There are no big issues left, though, except for making the API stable and supporting the improved build description language. This should be done within another compiler release cycle.

Am 01.06.2015 um 09:19 schrieb Iain Buclaw via Digitalmars-d:
>
> On 1 Jun 2015 09:09, "Manu via Digitalmars-d"
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>  >
>  > On 1 June 2015 at 16:54, Iain Buclaw via Digitalmars-d
>  > <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>  > >
>  > > On 1 Jun 2015 08:45, "Nick Sabalausky via Digitalmars-d"
>  > > <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>>
> wrote:
>  > >>
>  > >> On 06/01/2015 01:57 AM, Manu via Digitalmars-d wrote:
>  > >>>
>  > >>> On 1 June 2015 at 15:05, Brad Anderson via Digitalmars-d
>  > >>>>
>  > >>>> That's not really how you use dub though. dub simply isn't a
> good fit
>  > >>>> for
>  > >>>>
>  > >>>> people who want it to be a system package manager. Its goals are
>  > >>>> different.
>  > >>>> If people want that they should work on getting libraries added
> to their
>  > >>>> preferred system's package registries.
>  > >>>
>  > >>>
>  > >>> Right, so, someone decide a path, we'll write it on dlang.org
> <http://dlang.org>, and
>  > >>> then everyone will agree and fall in line :)
>  > >>>
>  > >>
>  > >> Not sure how serious/joking you are about that, but when has
> declaring a
>  > >> standard whatever like that ever worked for anything ever? ;)
> Linux can't
>  > >> even agree with Linux on where things should go, apparently that's
> why C on
>  > >> linux has pkg-config.
>  > >>
>  > >
>  > > Leave it to the distribution is the safe option in my experience.
> To have
>  > > something along the lines of what Manu wants, I guess we need
> something like
>  > > virtualenv to allow building in a clean/standard environment.
>  >
>  > Yeah, I think I can see 2 parallel problems here.
>  > 1. There is a lib installed from a -dev package managed by the
>  > distribution... I just want the complementary .d files. (this is what
>  > I actually care about)
>  > 2. There is some open-source D code which isn't distributed as a
>  > binary, it's just a git repo and you fetch it and build it locally. (I
>  > find that I rarely need this, so I don't have much opinion on this
>  > case)
>  >
>  > For case 1, my preference would be a distro managed package alongside
>  > the lib itself, and installed into a standard location. If dub could
>  > pull the bindings I want and put them in some common location, fine.
>  > For case 2... I dunno. What if you offer a lib that falls into case 2;
>  > source is available, user can fetch and build against it locally, but
>  > it contains C code too? dub isn't exactly a build system which can
>  > express a complex build environment.
>  > I can't create a dub package for my engine, which might be of interest
>  > to D gamedevs.
>
> In one sense this can be solved at the distribution level.  If dub was
> provided through your package manager, the package maintainers can
> ensure that dub was configured to understand where all system sources
> are located (or will be located).
>
> Can all of dubs default settings be dumped to json and be overriden?
>

It would be possible to put a ".dub/settings.json" with custom settings into the distribution package (hmm, /etc/dub/settings.json or similar should probably supported in addition to that...).

Am 01.06.2015 um 17:16 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>":
> Since this thread seems to have turned into a wishlist for dub features,
> I'm going to add one:
>
> Undeprecate dependencies on git branches. They are really not different
> from dependencies with fuzzy "~>" versions. For both, the exact selected
> version can be stored in dub.selections.json.
>
> Use case:
> Making a fix to a third-party project and sharing that fix with other
> team members. Having to create a temporary project on code.dlang.org
> just for that purpose is both a waste of time for developers and a waste
> of resources of community infrastructure.

They are only deprecated within dub.json. You can still use them within dub.selections.json. But really, branch based dependencies are simply a broken feature. They are completely different to version ranges, because they are not at all comparable (to other branches or versions) - at least without completely committing to GIT and starting to walk the GIT commit graph.

You can also check out certain branches locally and use "dub add-local" or "dub add-path" to let DUB use it instead of the publicly registered one.

Am 01.06.2015 um 20:49 schrieb Steven Schveighoffer:
> (...)
> Sorry, I suppose it's a small burden if you use dub frequently. I don't.
> Look what happens when I initialize a dub project:
>
> {
>      "name": "testdub",
>      "description": "A minimal D application.",
>      "copyright": "Copyright © 2015, steves",
>      "authors": ["steves"],
>      "dependencies": {
>      }
> }
>
> Cool, I can figure out how to massage all the existing strings, except,
> hm... dependencies. What goes in there?
>

As of recently, you can also directly specify dependencies to the "dub init" command, for example "dub init myproject tango derelict-gl". There was also the suggestion to make dub init (without arguments) interactive, which would make this a really easy matter.

On Thursday, 4 June 2015 at 08:51:02 UTC, Sönke Ludwig wrote:
> Am 01.06.2015 um 17:16 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>":
>> Since this thread seems to have turned into a wishlist for dub features,
>> I'm going to add one:
>>
>> Undeprecate dependencies on git branches. They are really not different
>> from dependencies with fuzzy "~>" versions. For both, the exact selected
>> version can be stored in dub.selections.json.
>>
>> Use case:
>> Making a fix to a third-party project and sharing that fix with other
>> team members. Having to create a temporary project on code.dlang.org
>> just for that purpose is both a waste of time for developers and a waste
>> of resources of community infrastructure.
>
> They are only deprecated within dub.json. You can still use them within dub.selections.json.

This is exactly the wrong way round. dub.selections.json must only contain exact versions. That's its purpose after all.

See Ruby's bundler as an example:
http://bundler.io/v1.9/rationale.html
Especially the parts about Gemfile.lock, which is their equivalent of dub.selections.json.

> But really, branch based dependencies are simply a broken feature. They are completely different to version ranges, because they are not at all comparable (to other branches or versions) - at least without completely committing to GIT and starting to walk the GIT commit graph.

Why would you even want to compare them, except for equality? There are only the following cases AFAICS, none of which require an order:

1) Package is not yet in dub.selections.json:
=> Clone/update repo, checkout the branch, and put the exact commit id into dub.selections.json.
2) Package is already included in dub.selections.json:
=> All fine, nothing needs to be done.
3) An upgrade of the package has been requested:
=> Same as 1)

There could be situations during dependency resolution where you want to check whether a given commit is part of a branch, but that's a different (and easier) problem.

>
> You can also check out certain branches locally and use "dub add-local" or "dub add-path" to let DUB use it instead of the publicly registered one.

This is not an option in a larger team. Everyone would have to do that manually, or you'd need to write a custom script to do what is actually the package manager's task.

On 2015-06-04 12:30, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Thursday, 4 June 2015 at 08:51:02 UTC, Sönke Ludwig wrote:
>> Am 01.06.2015 um 17:16 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?=
>> <schuetzm@gmx.net>":

>> You can also check out certain branches locally and use "dub
>> add-local" or "dub add-path" to let DUB use it instead of the publicly
>> registered one.
>
> This is not an option in a larger team. Everyone would have to do that
> manually, or you'd need to write a custom script to do what is actually
> the package manager's task.

I would prefer to just stick a Git URL + branch in the dub.json file, just as with the Gemfile in Bundler.

-- 
/Jacob Carlborg

On 6/4/15 4:58 AM, Sönke Ludwig wrote:
> Am 01.06.2015 um 20:49 schrieb Steven Schveighoffer:
>> (...)
>> Sorry, I suppose it's a small burden if you use dub frequently. I don't.
>> Look what happens when I initialize a dub project:
>>
>> {
>>      "name": "testdub",
>>      "description": "A minimal D application.",
>>      "copyright": "Copyright © 2015, steves",
>>      "authors": ["steves"],
>>      "dependencies": {
>>      }
>> }
>>
>> Cool, I can figure out how to massage all the existing strings, except,
>> hm... dependencies. What goes in there?
>>
>
> As of recently, you can also directly specify dependencies to the "dub
> init" command, for example "dub init myproject tango derelict-gl".

That's nice. But it still isn't self-explanatory. Nor additive.

> There
> was also the suggestion to make dub init (without arguments)
> interactive, which would make this a really easy matter.

This would be better, but I still think a way to add dependencies should be supported on the command line. Something like dub depend someproject. You don't always know what a project will need at the beginning.

Of course, you could just say "well, edit the json file!". You really need a format that supports comments...

In any case, this doesn't negate the concerns others have raised.

I don't mean to bash dub, it's better than nothing. But I haven't used it for any real project yet. And when I did use it, it was not a straightforward experience.

-Steve

On Thursday, 4 June 2015 at 13:07:50 UTC, Steven Schveighoffer wrote:
> That's nice. But it still isn't self-explanatory. Nor additive.

Do you think it'd be better to have a list of flags to specify dependancies?
Like :
dub init myProj -d tango -d derelict-gl --dependency=vibe-d

> This would be better, but I still think a way to add dependencies should be supported on the command line. Something like dub depend someproject. You don't always know what a project will need at the beginning.

Agree here, this is something I plan on working on soon.

> Of course, you could just say "well, edit the json file!". You really need a format that supports comments...
>
> In any case, this doesn't negate the concerns others have raised.
>
> I don't mean to bash dub, it's better than nothing. But I haven't used it for any real project yet. And when I did use it, it was not a straightforward experience.
>
> -Steve

Am 04.06.2015 um 12:30 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>":
> On Thursday, 4 June 2015 at 08:51:02 UTC, Sönke Ludwig wrote:
>> Am 01.06.2015 um 17:16 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?=
>> <schuetzm@gmx.net>":
>>> Since this thread seems to have turned into a wishlist for dub features,
>>> I'm going to add one:
>>>
>>> Undeprecate dependencies on git branches. They are really not different
>>> from dependencies with fuzzy "~>" versions. For both, the exact selected
>>> version can be stored in dub.selections.json.
>>>
>>> Use case:
>>> Making a fix to a third-party project and sharing that fix with other
>>> team members. Having to create a temporary project on code.dlang.org
>>> just for that purpose is both a waste of time for developers and a waste
>>> of resources of community infrastructure.
>>
>> They are only deprecated within dub.json. You can still use them
>> within dub.selections.json.
>
> This is exactly the wrong way round. dub.selections.json must only
> contain exact versions. That's its purpose after all.

A branch *is* an exact version as far as DUB goes (just one that changes over time). But to make use of any commit relationships within a branch, it would have to gain specific knowledge of GIT or other version management systems.

Adding support for commit hashes in dub.selections.json is still TBD, but would be another alternative.

BTW, my primary concern with all of these things is retaining a healthy public package eco system. I personally suspect that this is much more important for the language as a whole rather than pleasing every single taste. This doesn't mean that the latter isn't a worthwhile goal, but to me the former has always been more important. What is missing is a proposal how to solve both issues at the same time.

>
> See Ruby's bundler as an example:
> http://bundler.io/v1.9/rationale.html
> Especially the parts about Gemfile.lock, which is their equivalent of
> dub.selections.json.
>
>> But really, branch based dependencies are simply a broken feature.
>> They are completely different to version ranges, because they are not
>> at all comparable (to other branches or versions) - at least without
>> completely committing to GIT and starting to walk the GIT commit graph.
>
> Why would you even want to compare them, except for equality? (...)

For example for conflict resolution. This is the foremost reason why the *have* to be banned from dub.json. You can't really know if a branch matches/is compatible with any particular version (range) or another branch, so you have to either make an arbitrary guess (always prefer the branch; always prefer the version; always prefer "master", but a tagged version otherwise; etc.), or always issue a version conflict error.

The practical effect that was already very visible in the existing ecosystem was that packages tended to separate into two clusters. One cluster that used branch dependencies and another that used version dependencies. Both incompatible with each other. It also meant that a lot of people didn't bother to make any version tags at all, which is understandable, but also a very bad influence to the stability of the ecosystem. Semantic versioning, if used correctly, is a very important factor in that regard.

The compromise solution to allow branch based dependencies only in the version selection file doesn't really have drawbacks, but dodges all of those issues by moving the decision to the root of the dependency tree.

>
>>
>> You can also check out certain branches locally and use "dub
>> add-local" or "dub add-path" to let DUB use it instead of the publicly
>> registered one.
>
> This is not an option in a larger team. Everyone would have to do that
> manually, or you'd need to write a custom script to do what is actually
> the package manager's task.

Using dub.selections.json should be the right tool then. You could of course also use things like git submodules + path based dependencies in this case, there is no need to force everything into one schema (especially when it doesn't fit well, such as versions and branches).

On 06/04/2015 04:39 AM, Sönke Ludwig wrote:
>
> Of course you could make the system completely build
> tool agnostic, but then you'd basically lose interoperability between
> packages, as each package might choose its own build tool.
>

With this PR and the upcoming follow-up to add --format=(list|some_compiler|whatever), there is NO issue with package interoperability (as long as a package's "import-paths" is correct):

https://github.com/D-Programming-Language/dub/pull/572

Note that even WITHOUT dub, packages from different buildsystems *already* interop just fine. Even in C-land. All you ever need for packages to work together is the appropriate "build this package" command and the import/lib paths for the compiler/linker. Buildsystem is a package-local issue, not a cross-package issue.