On 11 September 2013 06:48, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> 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 front-end for dub floating around?
Something like the cygwin package installer comes to mind... (nothing fancy)

I've used dub once, I was very satisfied with the experience. I think a front-end where you can browse the repository and select/deselect packages conveniently would be a great addition to the experience, if it's not already available.

On 2013-09-26 09:44, Manu wrote:

> Is there a front-end for dub floating around?
> Something like the cygwin package installer comes to mind... (nothing fancy)
>
> I've used dub once, I was very satisfied with the experience. I think a
> front-end where you can browse the repository and select/deselect
> packages conveniently would be a great addition to the experience, if
> it's not already available.

I'm wondering how that would look like. Because apparently people don't like dub to actually install packages. If dub doesn't install packages I don't think it would gain much of over browsing the registry:

http://code.dlang.org/

-- 
/Jacob Carlborg

On 26 September 2013 18:24, Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-26 09:44, Manu wrote:
>
>  Is there a front-end for dub floating around?
>> Something like the cygwin package installer comes to mind... (nothing
>> fancy)
>>
>> I've used dub once, I was very satisfied with the experience. I think a front-end where you can browse the repository and select/deselect packages conveniently would be a great addition to the experience, if it's not already available.
>>
>
> I'm wondering how that would look like. Because apparently people don't like dub to actually install packages. If dub doesn't install packages I don't think it would gain much of over browsing the registry:
>
> http://code.dlang.org/


Is that not a package list?

I only just skimmed this thread, but it seemed dub installs packages to
me...
What did it install when I told it to install vibe.d and some other
companion pieces then?

On Thursday, 26 September 2013 at 06:59:05 UTC, 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.

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.

On Thursday, 26 September 2013 at 07:44:25 UTC, Manu wrote:
> I've used dub once, I was very satisfied with the experience. I think a
> front-end where you can browse the repository and select/deselect packages
> conveniently would be a great addition to the experience, if it's not
> already available.

Do you mean a tool that edits package.json file?
I see little gain in having GUI for that.

On Thursday, 26 September 2013 at 06:59:05 UTC, 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.

Good look getting all those small trivial libraries into official repositories. Actually, some distros even prohibit pure source packages at all.

You should install it because you are tired of satisfying build dependencies manually and it is a bit more robust than git submodules. Pretty much all.

On Thursday, 26 September 2013 at 11:17:29 UTC, Dicebot wrote:
> ..

:%s/look/luck/g

On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin 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 am against even user-wide installation. It should provide environment for building other dub packages, not interfere with normal way system operates. Lot of developers are terrible at packaging and once you provide even limited tool to do it "dirty" way it will be forced on users. This has already made ruby projects unusable for anyone but ruby developers, I don't want this for D.

AFAIK currently `dub install` does hardly anything more than just cloning matching repository and remembering it in local registry. `dub cache` would have been probably better name. And `dub install --system` should really just be deprecated as very bad practice.

On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg wrote:
> Instead I need to package my application and libraries for all the various of package managers out there. Not to mention neither Mac OS X or Windows comes with a package manager installed by default.

No, you just let maintainers interested in target systems to take care of it. And package for 2-3 you care about _personally_. It is an obsolete idea that developer of a library/program should do any packaging at all. If your program is any good, there will always be volunteers to adapt it nicely for their beloved systems.

> It's like buying a car. I buy a car for getting from A to B. I have bought my car and prepares to get from A to B. The car won't start, hmm ..., oh it has no engine. I have to figure out myself how to buy and install the engine. It's only half way there.

Yeah and what you propose is like mandatory requirement to have a separate home for every single electronics vendor. Want to buy something from different one? You must buy new home for it, period. (Well, feels like we are actually going there in real like >_<)

> It's the same with dub. I install a package to use the tool. But wait, it actually _don't_, it just clones the repository.  I have to figure out myself how to compile and install the tool. It's only half way there.

This is just plain wrong. dub takes care of proper compilation of any tool that is contained in its registry, you don't need to do anything about it. But there is no possible legitimate reasons to install it. During development you can pretty much run in locally from the source dir. For end user distribution you must go system-specific way.

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

It is neither a build tool nor package manager. It is a tool that aggregates different possible build tools backends and takes care of resolving build dependencies for them. Nothing more, nothing less.

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 that aggregates different possible build tools backends and takes care of resolving build dependencies for them. Nothing more, nothing less.

I think, the max it should be able to do is to output .deb or .rpm (or .tgz) files.

After, it is the job the standard install mechanism on the host OS.