Am 27.09.2013 14:04, schrieb Jacob Carlborg:
> On 2013-09-10 22:48, Andrei Alexandrescu wrote:
>> We've been experimenting with http://code.dlang.org for a while and
>> things are going well. In particular Sönke has been very active about
>> maintaining and improving it, which brings further confidence in the
>> future of the project.
>>
>> We're considering making dub the official package manager for D. What do
>> you all think?
>
> The name "package.json" is already used by NPM (node package manager).
> Should we rename the package file or should we just ignore the conflict?
>

Although the conflict will probably not matter in practice, I think just "dub.json" would be better. The name "package.json" is still from the early days when it was called VPM.

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
> We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project.
>
> We're considering making dub the official package manager for D. What do you all think?
>
>
> Andrei

Well, you've started the mother of all bikeshed threads, as every dev/sysadmin has a different opinion on how to handle packages. ;) There have been some valid concerns raised about whether dub should do all the stuff it does, but I think they're largely moot at this point, given the small size of the D community.  Better a tool that does everything initially, as current D users are inevitably developers, which can then be split up and specialized later if necessary.


I've used dub on FreeBSD and was impressed with both the tool and how clean the code is, even though there were small linking/library incompatibilities that meant I had to hack a workaround into dub to compile vibe.d.  Sonke was remarkably responsive to my feedback, I cannot imagine there will be a better option for a D package manager and developer.

On 27/09/2013 12:53, Jacob Carlborg wrote:
> On 2013-09-27 13:22, Bruno Medeiros wrote:
>
>> It compiles packages when used as dependencies in another package, and
>> run with the "dub build" command.
>>
>> What perhaps you meant to say is that dub doesn't compile application
>> packages that it downloads from the registry. That might be true. Even
>> so, if you do "dub install" of one such package, then navigate to the
>> directory where it was installed, and do "dub build", it should compile
>> the executable. I haven't tried that myself though.
>
> Yes, it does. But that's where I draw the line with the "dub install"
> command actually installs or not. So since it doesn't build the package
> I wouldn't considered the package installed, which is what I expect from
> a command named "install". But what you already have said "cache" sounds
> like a better name for what it currently does.
>

"mirror" would also be a good name for what it currently does. But personally I'm not that bothered about "install".

-- 
Bruno Medeiros - Software Engineer

On 27/09/2013 14:00, Wyatt wrote:
> On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros wrote:
>>
>> To be fair, I don't entirely agree with this. End user
>> distribution/installation doesn't have to be system-specific. I can
>> see many interesting and useful use-cases for a cross-platform user
>> application package manager. It might be a real cool project if done
>> properly.
>
> That's CPAN.  You just described CPAN.  It supports both system and user
> level package installing, bails properly when build deps are missing,
> and has enough metadata that we can support it from the system package
> manager for proper system-level depgraph and file tracking.  If there's
> a wheel we want to steal or reinvent, this is THE one.
>
> But I think it's important to remember it would be complete cat puke
> like ruby packaging if they didn't have PAUSE [0]; clear,
> moderately-strict submission guidelines [1] (especially for newcomers);
> and PrePAN, for feedback and discussion BEFORE it goes up.
>
> The latter, and community involvement in general, is possibly the most
> important aspect of this process because the community is ultimately
> your userbase. (It's not so knock-down/drag-out as Phobos module
> reviews, but it's a great source of sanity checking.[2])
>
> -Wyatt
>
> [0] http://www.cpan.org/modules/04pause.html Recommend reading the whole
> thing.
> [1] http://search.cpan.org/~rjbs/perl-5.18.1/pod/perlnewmod.pod
> [2] http://prepan.org/module/nXWJ8Y9sBtw A good recent example

I would only consider a cross-platform user application package manager to be interesting (that is, useful to a significant level) if it's not tied to any particular language (or platform).

-- 
Bruno Medeiros - Software Engineer

On 26/09/2013 21:05, Jacob Carlborg wrote:
>> Are... you... serious?... O_O
>>
>> There are incredibly important benefits for development-time usage.
>> To automatically fetch the required dependencies, making sure they are
>> correct for you application. Easily upgrade the version of dependencies?
>> Support multiple build configurations (including for example unittest
>> runners)?
>
>
>> Supporting all the previous functionality in a way that is
>> replicable across different machines?
>
> It's not, that's another big issue with dub. It doesn't lock the
> dependency graph. If you have the packages:
>
> My own package:
>
> {
>      "name": "foo",
>      "dependencies": {
>          "bar": "=0.0.1"
>      }
> }
>
> Third party package:
>
> {
>      "name": "bar",
>      "dependencies": {
>          "xyz": ">=0.0.1"
>      }
> }
>
> Another third party package:
>
> {
>      "name": "xyz"
> }
>
> Say I install package "foo" on a machine. It will install package
> "bar-0.0.1" and "xyz-0.0.1" just as it should. Then an hour later I
> install the same package, "foo", on a different machine. Then suddenly
> it install "xyz-0.0.2". Surprise surprise, it's not the same application
> anymore and you have no idea if the application is working or not.
>
> Of course, it's unlikely this will happen within an hour. But try six
> months later and you might end up with a completely different application.

From what I understand, for dependency graph locking to work at all, then each package (as stored in the central package repository) would have to specify its full dependency graph in the package specification. So the foo package would have to specify not only the bar dependency, but also xyz=0.0.1 as a dependency. Isn't that how it would work?
If so, I think that might be too constricting, and might introducing other kinds of problems and limitations. (what if you know xyz=0.0.2 is safe to use, and want to install foo with that?)

Rather, I think dub should adopt Semantic Versioning as part of its recommended practices for package versioning:
http://semver.org/spec/v2.0.0.html
In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an upper bound on the version is required, to allow breaking changes in xyz.


-- 
Bruno Medeiros - Software Engineer

On 27/09/2013 18:12, Sönke Ludwig wrote:
> Am 27.09.2013 14:04, schrieb Jacob Carlborg:
>> On 2013-09-10 22:48, Andrei Alexandrescu wrote:
>>> We've been experimenting with http://code.dlang.org for a while and
>>> things are going well. In particular Sönke has been very active about
>>> maintaining and improving it, which brings further confidence in the
>>> future of the project.
>>>
>>> We're considering making dub the official package manager for D. What do
>>> you all think?
>>
>> The name "package.json" is already used by NPM (node package manager).
>> Should we rename the package file or should we just ignore the conflict?
>>
>
> Although the conflict will probably not matter in practice, I think just
> "dub.json" would be better. The name "package.json" is still from the
> early days when it was called VPM.

Any chance that Dub packages could be called something else instead, such as "bundles", throughout the documentation, wiki, etc.? The point here would be to limit cognitive confusion/overlap with D language packages. It's just a minor cleanup I know, and of subjective value, but still I think it would be nicer...

-- 
Bruno Medeiros - Software Engineer

On 08/10/2013 11:51, Bruno Medeiros wrote:
> Rather, I think dub should adopt Semantic Versioning as part of its
> recommended practices for package versioning:
> http://semver.org/spec/v2.0.0.html
> In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
> upper bound on the version is required, to allow breaking changes in xyz.

Doh, I should have checked this before I posted, but dub does this already:
http://code.dlang.org/package-format#version-specs

That means all packages (at least production ready ones) should use upper bounds on their dependencies.

-- 
Bruno Medeiros - Software Engineer

On Tuesday, 8 October 2013 at 10:18:03 UTC, Bruno Medeiros wrote:
>
> I would only consider a cross-platform user application package manager to be interesting (that is, useful to a significant level) if it's not tied to any particular language (or platform).

...Oh, you're looking for Gentoo Prefix.  Got it.  Here you go: http://www.gentoo.org/proj/en/gentoo-alt/prefix/ :)

-Wyatt

On 2013-10-08 12:51, Bruno Medeiros wrote:

>  From what I understand, for dependency graph locking to work at all,
> then each package (as stored in the central package repository) would
> have to specify its full dependency graph in the package specification.
> So the foo package would have to specify not only the bar dependency,
> but also xyz=0.0.1 as a dependency. Isn't that how it would work?

No, now necessarily. Using Bundler it works like this:

* You have your Gemfile, corresponds to package.json in dub
* You run "bundle install"

* When you do that it will create a new file, Gemfile.lock. This file contains the complete dependency graph of what it just installed.

* Running "bundle install" when Gemfile.lock exist, it will read Gemfile.lock instead of Gemfile

By the way, the registry (package repository) need to be able to figure you the complete dependency graph, otherwise it won't be very effective. It should only require one single HTTP request to the registry to get the complete list of dependencies of a given package.

> If so, I think that might be too constricting, and might introducing
> other kinds of problems and limitations. (what if you know xyz=0.0.2 is
> safe to use, and want to install foo with that?)

The way I've done that using Bundler is to explicitly specify that as a direct dependency, in this case of "foo". I don't know if there's a better way.

> Rather, I think dub should adopt Semantic Versioning as part of its
> recommended practices for package versioning:
> http://semver.org/spec/v2.0.0.html
> In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
> upper bound on the version is required, to allow breaking changes in xyz.

Semantic versioning helps, but it won't solve the problem. I wouldn't trust that a library actually follows the semantic versioning scheme. It's quite easy to accidentally add new API without incrementing the middle number. Or break the API.

-- 
/Jacob Carlborg

On 2013-10-08 12:55, Bruno Medeiros wrote:

> Any chance that Dub packages could be called something else instead,
> such as "bundles", throughout the documentation, wiki, etc.? The point
> here would be to limit cognitive confusion/overlap with D language
> packages. It's just a minor cleanup I know, and of subjective value, but
> still I think it would be nicer...

What if it always said "dub package"? There's always the chance of confusion. On Mac OS X a "bundle" is a special folder containing an executable or dynamic library plus its resources.

-- 
/Jacob Carlborg