Am 11.09.2013 00:30, schrieb Brad Anderson:
> On Tuesday, 10 September 2013 at 22:06:28 UTC, luminousone wrote:
>> And license acknowledgement, this is much more important with
>> source libraries then it is with say apt on Ubuntu. Accidentally
>> polluting a bsd project or a closed source project with LGPL/GPL
>> code would be very bad, And often these package management
>> systems obscure what the sources license actually is by simply
>> not showing it or informing the user.
>>
>
> There is a license field in the dub package file.  It would be neat if
> dub could warn you if it found incompatible license in your dependencies
> though.

I've added two enhancement requests for this:

https://github.com/rejectedsoftware/dub/issues/117
https://github.com/rejectedsoftware/dub-registry/issues/14

Am 11.09.2013 00:06, schrieb luminousone:
> Projects that haven't had an update for an excessive amount of
> time should likely be hidden but still available except in cases
> where it is known to be unchanged without need for updates(such
> as most wrappers).

Agreed. Maybe some other knowledge, such as how many other (active) packages depend on it, or how often it is still downloaded, can help to get a robust automatic measure.

Am 11.09.2013 01:17, schrieb Peter Williams:
> On 11/09/13 06: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?
>
> Is there a 64 bit rpm for dub?
>
> Peter
>

AFAIK nobody has started to make RPM's yet (only DEB, AUR and Homebrew so far). Manual installation is trivial though (just ./build.sh and symlink the executable to /usr/local/bin or similar, or put it in PATH).

Am 11.09.2013 02:18, schrieb Martin Nowak:
> On 09/10/2013 10:48 PM, 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
>
> I think the package format is really good.
> The registry is essential but needs to support categories, searching and
> some sort of quality ranking (voting?) for future grow.

Full ACK, this is quite critical IMO as the raw package list already provides less than an optimal overview. There are enhancement requests for these in the dub-registry issue tracker [1]. If anyone wants to help out, this is probably one of the most rewarding areas right now (I'll eventually get to it, but things are very busy here).

[1]: https://github.com/rejectedsoftware/dub-registry/issues

Am 11.09.2013 03:49, schrieb Nathan M. Swan:
> 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
>
> I'm all in favor.
>
> Careful about the dependencies though, particularly for dub-registry.
> It's dependent on userman and vibe-d, which is dependent on openssl,
> libevent, and libev (in Deimos).
>

That's right, at least for DUB itself, all external dependencies have been eliminated, though (except Phobos/libcurl).

For the registry site, however, it would be impractical to remove the vibe-d dependency (means a complete rewrite with some other dependency used instead). But should it ever become an issue, the userman dependency could be replaced more easily.

Am 11.09.2013 06:06, schrieb Jason den Dulk:
> On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
>
>> We're considering making dub the official package manager for D. What
>> do you all think?
>
> I think it is a good idea. Having a broad library available for
> developers to use is a big boost to productivity.
>
> However, I agree with luminousone that there need to be some rules about
> inclusion in the registry. Here are my ideas.
>
> 1) Must be legal.
> 2) Must be release usable.
> 3) Always has an active caretaker.
> 5) Have a clear & precise descrption of what it does.

I think most of this would best be handled by the community using some form of voting/commenting system (with the option for moderation in case of 1) or by automatically fading out packages that fail certain metrics over time (last update to long ago, to few recent downloads, too few other packages depending on it etc.).

> 4) Must compile and run with a "reasonably recent" version of the
> official compiler.

Having an integrated CI solution would not only solve 4, but would also allow things such as automatic online documentation for each package. But for so many packages this will of course be difficult in terms of available hardware power and security issues.

> 6) Have proper licensing.

This should be reasonably automated by enforcing that a proper license field is in place and enforcing proper license nesting for known license types (see [1] and [2]).

[1]: https://github.com/rejectedsoftware/dub-registry/issues/14
[2]: https://github.com/rejectedsoftware/dub/issues/117

On 2013-09-11 08:28, Sönke Ludwig wrote:

> Agreed. Maybe some other knowledge, such as how many other (active)
> packages depend on it, or how often it is still downloaded, can help to
> get a robust automatic measure.

How many total downloads would be nice as well. In RubyGems there are often similar packages and it can be hard to choose which to use. Example:

* bootstrap-will_paginate. 257 475 downloads

* will_paginate-bootstrap. 84 776 downloads

Obviously I'm going to choose the one with most downloads, if there are any critical differences.

-- 
/Jacob Carlborg

On 2013-09-11 08:56, Sönke Ludwig wrote:

> Having an integrated CI solution would not only solve 4, but would also
> allow things such as automatic online documentation for each package.
> But for so many packages this will of course be difficult in terms of
> available hardware power and security issues.

Just use Travis CI, or similar. Unfortunately Travis CI currently only supports Linux and Mac OS X. It doesn't support multiple platforms for a single project.

http://travis-ci.org

-- 
/Jacob Carlborg

On 2013-09-11 06:06, Jason den Dulk wrote:

> 1) Must be legal.

What exactly does this mean in this context?

> 4) Must compile and run with a "reasonably recent" version of the
> official compiler.

I think it's better to specify a compiler and version in the package file.

-- 
/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?

Unfortunately I have to say no to its current state.

The biggest issue I have with dub is that it's really doesn't install packages, at least not in the traditional sense. I cannot just run "dub install foo" and then "foo --help". It will only clone the repository, not install, or install anything. It basically only supports source packages, which makes it mostly useless for tools/application compiling to executables.

I would say, compiling and installing executables is a must. It would be nice if it could compiling libraries as well.

Some other minor issues:

* The registry automatically tracks the git repository. If I register a new project it will default to "master" if no tags are available. I would prefer to tell the registry myself what's available.

* By default a package has the target type "autodetect" which will try and build an application and a library, as far as I understand it. Many projects cannot be built as an application, they're just libraries. Or the other way around.

* When running "dub init foo" you get a directory structure like this:

foo
  |
  |__ public
  |
  |__ source
  |   |
  |   |__ app.d
  |
  |__ views
  |
  |__ package.json

This directory structure is very centered around vibe.d. This was fine when dub was primary the package manger for vibe.d, but I don't think it should look like this if it becomes the default package manager for D. I mean, "public" and "views", why would I need those. As I understand it "views" can be used for string imports, in that case it would be better to call it "res" or "resources" instead. Most non vibe.d projects would probably not need this at all so I'm not sure if this should be default.

* Tries to be a build tool and a package manager and at same time

* I'm not sure how it installs indirect dependencies. I'm suspecting it will always install the latest version of an indirect dependency if nothing else is specified, which I think is really bad for systems in a production environment. When the project is built it should locked down and all the versions of the dependencies, including indirect dependencies.

Say I have a package file looking like this:

{
    "name": "myproject",
    "dependencies": {
        "foo": "0.0.1"
    }
}

And

{
    "name": "foo",
    "dependencies": {
        "bar": ">= 0.0.1"
    }
}

And

{
    "name": "bar"
    "dependencies": {
    }
}

The latest version of "bar" is 0.0.1.

When building "myproject" it should lock down "bar" to the latest version matching the requirement, that is 0.0.1.

If a new version of "bar" is out, say 0.0.2, and I'm then installing "myproject" on a different computer, I should get the exact same packages, that is "bar" should be at version 0.0.1.

If I want a later version of "bar" I should explicitly tell dub that.

In the end I think it's great if we get a package manager for D. But in its current state I'm not overly enthusiastic about dub. But depending on what other thinks and Sönke is willing to take some of this into consideration I think it could be a good addition to the D tools.

-- 
/Jacob Carlborg