On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:
> On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:
>> On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg wrote:
>> It is neither a build tool nor package manager. It is a tool

While speaking about the dub, somebode with edit rights could take care of this little glitch?

On the page:

http://code.dlang.org/download

The link in:

"Debian packages are available as part of Jordi Sayol's D APT repository."

should be updated from:

https://code.google.com/p/d-apt/wiki/APT_Repository

to:

http://d-apt.sourceforge.net/

On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin wrote:
> On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg wrote:
>> On 2013-09-25 18:14, Bruno Medeiros wrote:
>>
> Install packages: yes, but locally, primarily for dub/development use. Not system-level library installations for end-users.
>
> I think when people are talking about not wanting it to install things they are talking about the latter, not the former.

I feel that, in order for this behaviour to be truly local to the compiler and OS-independent, that the interface between the compiler and dub is required, to inform the former about the existence of these packages.

Currently, this is a compiler-by-compiler approach but, if standardized, it will kinda go into language/compiler specs.

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 hate to be /that guy/, but...

Sönke, have you considered using TOML as an editable serialization/configuration format?
https://github.com/mojombo/toml

It's easy on the eyes, has a simple grammar, and seems to have at least /some/ buy-in from other communities.

I'm just not sure if it has all of the features you desire; you would know better than I.

On 26/09/2013 07:57, Jacob Carlborg wrote:
> On 2013-09-25 17:51, Bruno Medeiros wrote:
>
> I have to figure out myself how to compile and install the tool. It's only half way there.
>

You have to install the yourself, yes. Not compile it. Dub should take care of the compiling aspect.
If you just want to use the tool executable artifact, dub is likely not right for you. If the tool requires more complex installation, the tool developers should provide their own installer or OS distribution package.


>> What dub should be first and foremost is a structured build tool (and
>> build specification) for D projects.
>
> There's nothing wrong with being a build tool. But currently dub tries
> to be way more than a build tool. I don't think a build tool should have
> any business in downloading packages, or download anything.
>

A build tool should not download anything? That is antiquated C/C++/make way of thinking. Popular build tools for modern languages all do downloading, for example Apache Maven (for Java), Gradle (for lots of different languages), and even RubyGems.
You might say RubyGems is a package manager, and not a build tool. But in practice it is both actually, even if it is not called a build tool: It fullfills the the equivalent goal as structured build tools like Maven or Graddle do for other language, the distinction is only less clear becase Ruby as a language can be easily interpreted and does require an overt "compilation/build" phase to generate an executable.

-- 
Bruno Medeiros - Software Engineer

On 26/09/2013 07:59, Jacob Carlborg wrote:
> On 2013-09-25 18:14, Bruno Medeiros wrote:
>
>> But this is all for development-time usage. To have the same tool try to
>> be an executable installation manager is another thing entirely and, in
>> my opinion quite ill-suited for dub (see related OP). Where did this
>> idea even come from??
>
> If dub doesn't install packages, why the h*ll should I use it in the
> first place? I can just use the system package manager.
>

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? Have other tools such as IDEs understand the source and build structure of your application/project/library??

System package managers don't support this because they are not cross-platform. Even if cross-platform wasn't an issue, there might still be several shortcomings or inadequacies with OS package managers because they are more often geared torwards end-user installation, not development-time usage.

-- 
Bruno Medeiros - Software Engineer

On 26/09/2013 12:39, Dicebot wrote:
> During development you can pretty much run in locally from the source
> dir. For end user distribution you must go system-specific way.

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.
I just don't think dub should aim for that goal. It should mainly be a build tool and package manager for development-time usage.

-- 
Bruno Medeiros - Software Engineer

On 26/09/2013 15:16, Bruno Medeiros wrote:
> To automatically fetch the required dependencies, making sure they are
> correct for you application.

When I say "correct" here, I also mean "compatible", in case that's not clear.

-- 
Bruno Medeiros - Software Engineer

On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros wrote:
> On 26/09/2013 12:39, Dicebot wrote:
>> During development you can pretty much run in locally from the source
>> dir. For end user distribution you must go system-specific way.
>
> 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.
> I just don't think dub should aim for that goal. It should mainly be a build tool and package manager for development-time usage.

I mean that it must respect rules and guidelines of target system. It is entirely possible to abstract lot of details away, there is a PackageKit for example it it does work pretty good. But it works by incorporating knowledge of all specific package managers and quirks inside, something I don't think we want to spend time on in dub.

On Thursday, 26 September 2013 at 12:14:42 UTC, eles wrote:
> On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:
>> On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:
>>> On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg wrote:
>>> It is neither a build tool nor package manager. It is a tool
>
> While speaking about the dub, somebode with edit rights could take care of this little glitch?
>
> On the page:
>
> http://code.dlang.org/download
>
> The link in:
>
> "Debian packages are available as part of Jordi Sayol's D APT repository."
>
> should be updated from:
>
> https://code.google.com/p/d-apt/wiki/APT_Repository
>
> to:
>
> http://d-apt.sourceforge.net/

It'll be fixed once Sönke merges this: https://github.com/rejectedsoftware/dub-registry/pull/16

Am 26.09.2013 16:24, schrieb Bruno Medeiros:
> On 26/09/2013 15:16, Bruno Medeiros wrote:
>> To automatically fetch the required dependencies, making sure they are
>> correct for you application.
>
> When I say "correct" here, I also mean "compatible", in case that's not
> clear.
>

Even C++ has them on Windows nowadays via NuGet,

http://docs.nuget.org/docs/reference/support-for-native-projects