On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig wrote:
> 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.

Simple idea: try to build the package via current DMD. If compilation false then the package too old (or we have DMD regression). So, it would be nice to have package autotester like for DMD/Phobos repositories.

On Wednesday, 11 September 2013 at 08:51:30 UTC, Jacob Carlborg wrote:
> On 2013-09-11 06:06, Jason den Dulk wrote:
>
>> 1) Must be legal.
>
> What exactly does this mean in this context?

You cannot include anything you do not have the legal right to include. I.E no copyright violations, no child porn software etc. It seems obvious, but it does need to be stated and is a standard part of any terms and conditions related to hosting and distribution.

>
>> 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.

Yes, but if the latest version the package is known to work with is more than 3 years old, it would be desirable to have that kept away from the up to date packages.

Am 11.09.2013 11:57, 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?
>
> 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.

Right now it is a pure development tool. It would be very nice to have end user installs somehow supported (either by directly installing application packages or by generating OS specific packages such as DEB or RPM). But since this enters a highly operating specific area and goes into direct competition with the OS package manager, I think it needs a lot of thought and caution to be generally useful and not possibly do more harm than good in the end. But yes, it should be a primary goal in my opinion, too.

>
> 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.

Why not _make_ a tag? But uploading zipped packages (or better specifying an external link) could be added as an alternative without much effort.

> * 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.

This is something that may still need some adjustments, but after all it's just a default when there is a "source/app.d" or "source/<packname>.d" file - an explicit "targetType": "xxx" will fix it when it's off.

>
> * 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.

"views" is maybe not general enough, but for what it's worth I'm also using it on other kinds of projects (e.g. to specify GUI templates). "res" might be a bit *too* general, but this could for sure be improved somehow. "public" is indeed specific for web stuff, so it may be the best to drop it by default.

I've also thought about offering a set of template projects usable for "dub init", so that there could e.g. be a true vibe.d skeleton, but by default it would be a minimal project with only a "source" folder.

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

Note that there is "dub describe" to extract the information relevant for actual building plus there is "dub generate xxx", so nothing is in the way of using a separate tool for building. But having integrated building IMO is highly convenient and keeping the build description in a standardized format is one of the key selling points.

>
> * 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.

You can put an additional "bar": "==0.0.1" dependency in the main package to lock it to a certain version. Or, of course, just use "==" in the bar package in the first place. This could also be implemented as a (semi-)automatic function along the lines of "dub lock-versions" and "dub lock-versions --upgrade".

On the other hand it's difficult to make a general statement that this is always the best way as this may for example prevent important security fixes to get incorporated unless the main package maintainer releases an explicit update...

>
> 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.
>

I'm quite confident that most points are not in conflict with the existing functionality and can be resolved just fine. Only the build/package combination is something that is too deeply rooted in the projects philosophy to just drop it. But it can be kept opt-out as far as possible and shouldn't harm special use cases.

On 11-9-2013 12:28, ilya-stromberg wrote:
> On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig wrote:
>> 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.
>
> Simple idea: try to build the package via current DMD. If compilation
> false then the package too old (or we have DMD regression). So, it would
> be nice to have package autotester like for DMD/Phobos repositories.

This way it actually knows the last compatible dmd version.

On Wednesday, 11 September 2013 at 11:31:11 UTC, Faux Amis wrote:
> On 11-9-2013 12:28, ilya-stromberg wrote:
>> On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig wrote:
>>> 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.
>>
>> Simple idea: try to build the package via current DMD. If compilation
>> false then the package too old (or we have DMD regression). So, it would
>> be nice to have package autotester like for DMD/Phobos repositories.
>
> This way it actually knows the last compatible dmd version.

Yes. And list of problem packages with compilation errors or broken dependencies.

On 2013-09-11 12:28, ilya-stromberg wrote:

> Simple idea: try to build the package via current DMD. If compilation
> false then the package too old (or we have DMD regression). So, it would
> be nice to have package autotester like for DMD/Phobos repositories.

Why should you be forced to constantly use the latest DMD? That can be a lot of work for the package developer for no gain.

-- 
/Jacob Carlborg

On Wednesday, 11 September 2013 at 12:26:05 UTC, Jacob Carlborg wrote:
> On 2013-09-11 12:28, ilya-stromberg wrote:
>
>> Simple idea: try to build the package via current DMD. If compilation
>> false then the package too old (or we have DMD regression). So, it would
>> be nice to have package autotester like for DMD/Phobos repositories.
>
> Why should you be forced to constantly use the latest DMD? That can be a lot of work for the package developer for no gain.

Because it is current D reality. Package that do not get updated to latest front-end version are used only if there is absolutely no other choice. Amount of inconvenience it causes to the user of the package is tremendous.

On 2013-09-11 13:03, Jason den Dulk wrote:

> Yes, but if the latest version the package is known to work with is more
> than 3 years old, it would be desirable to have that kept away from the
> up to date packages.

Three years is a bit different. I'm thinking more that it need to support multiple versions of the compilers because DMD breaks code in every single release. Why should I update a package that doesn't take advantage of any new features or bug fixes? It's just maintenance work.

-- 
/Jacob Carlborg

On Wednesday, 11 September 2013 at 09:57:48 UTC, Jacob Carlborg wrote:
> 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.

I am strongly against it. It is not a job of language package manager.

Implementing it properly will require to integrate the knowledge of every existing packaging system among every slightly popular OS / distro. Implement it as a hack with own package ecosystem and people will hate you.

It exists to simplify development. Users that run D-based programs should never ever be even aware of such thing as `dub`.

On 9/11/13 5:01, Brad Anderson wrote:
> I vote yes but only if Sönke feels it is ready. I suspect he has a few
> things he'll probably want done before this happens (the potential
> switch from JSON to SDL comes to mind).

SD-what?! Why would alienate people even more than we already do?

L.