On 2013-09-27 10:05, Dicebot wrote:

> It won't install it out of clone dir either in that mode. Why would it?
> Building is enough.

I'm not going to argue the semantics of "install". But yes, building is enough for that command.

> Currently you can define dependencies in your package.json to other dub
> packages. Those will be in your -I flags when building. I expect this to
> be also extended to -L and PATH, so that you can call any binaries from
> dependency packages as if they were installed (during build/test of your
> package). For this to work no real installation is needed, just building
> packages straight in the clone dir and keeping it.

If that's supported then "dub exec" won't give any advantage. But since that's currently isn't supported I suggested the "dub exec" command.

Unless "dub exec" can be used without a package.json file. That would work with packages you previously run "dub install" for.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

On 2013-09-27 13:24, Dicebot wrote:

> I think SDL looks best of those 3.

I agree, it almost looks like Ruby :). Although I don't really like that it's not a very common format, at least not as common as JSON.

-- 
/Jacob Carlborg

On Friday, 27 September 2013 at 11:50:28 UTC, Jacob Carlborg wrote:
> If that's supported then "dub exec" won't give any advantage. But since that's currently isn't supported I suggested the "dub exec" command.

I am pretty sure everyone has agreed it should be supported in the long run (and implementation effort is roughly the same as for `dub exec`). It naturally fits with current dub concept and mode of operations.

Don't exactly know what are Sonke plans about it though.

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?

-- 
/Jacob Carlborg

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

On Friday, 27 September 2013 at 13:00:58 UTC, Wyatt wrote:
> ...

afaik CPAN mixes development packages and distribution packages too, which I doubt is desired.

It may be unfortunate consequence of Perl interpreted nature though.

On Friday, 27 September 2013 at 13:03:20 UTC, Dicebot wrote:
> On Friday, 27 September 2013 at 13:00:58 UTC, Wyatt wrote:
>> ...
>
> afaik CPAN mixes development packages and distribution packages too, which I doubt is desired.
>
> It may be unfortunate consequence of Perl interpreted nature though.

Unless we're talking about different things, that's denoted in the META.json (I don't recall if the distinction existed in the META.yaml era) with e.g.
    "release_status" : "stable",
or
    "release_status" : "testing",

A proper tool can (and will) filter for this by default.

And to be explicitly clear, I'm not saying it's perfect for us as-is (or even perfect in general).  They're just the model citizen to take after.

-Wyatt

On Friday, 27 September 2013 at 13:29:26 UTC, Wyatt wrote:
> Unless we're talking about different things, that's denoted in the META.json (I don't recall if the distinction existed in the META.yaml era) with e.g.
>     "release_status" : "stable",
> or
>     "release_status" : "testing",

No, I mean that it does not make any difference between "programs written in perl to be widely used" and "libraries / tools for development in perl". For interpreted languages this distinction hardly makes sense, but for natively compiled ones it is pretty important.

And that was kind of the core point of the argument - can language-specific package manager be allowed to manage the former? I stand by the point that is a bad practice to provide any functionality that allows it, Jacob has opposite point of view :)

Funny, I started this with a clear mindset, but it ended up more nuanced than I expected.

On Friday, 27 September 2013 at 13:43:59 UTC, Dicebot wrote:
>
> No, I mean that it does not make any difference between "programs written in perl to be widely used" and "libraries / tools for development in perl". For interpreted languages this distinction hardly makes sense, but for natively compiled ones it is pretty important.
>
That's true, though at some level I wonder if its continued prevalence more comes back to CPAN supporting system and local-to-user installation simultaneously.  Users have been adding ~/bin to their $PATH since $EPOCH.

> And that was kind of the core point of the argument - can language-specific package manager be allowed to manage the former?

Not at the system level, it probably shouldn't.  Ideally, binary executables and libraries are the exclusive demesne of the system package manager.

As a historical footnote, I suspect part of why CPAN works the way it does is it was designed and (I think) released before RPM was even written. (It may even predate the original dpkg.)  More important than long precedent, though: Perl is largely self-contained by default, and can be made completely so [0].

In some sense, I _like_ the idea of installing module source to e.g. /usr/lib64/d2/site_d/2.63/ as long as dub is built into a normal install (control env with a config file in ~) and let it update the user's dmd.conf as a value-add [1].

> I stand by the point that is a bad practice to provide any functionality that allows it, Jacob has opposite point of view :)

I... turns out I have mixed feelings on this.  In the general sense, I'm strongly inclined to agree with you.  External package management undermines the sysadmin's ability to make good package installation decisions, splits the system dependency graph, and can create file conflicts.

But on the other hand, as long as there are sufficient options (preferable), a utility, or an API to interrogate dub for complete useful metadata; I'll refrain from getting too vehement about it.  This is only because that means system package managers _can_ properly integrate it, should they choose to do so. (cf. g-cpan [2])

See, I have my standards as a sysadmin, but don't forget policy victims, either: many others are stuck dealing with a CErtaiN Terrible Old diStribution and would probably appreciate a tool that isn't stuck mired in Really HorriblE poLicy when they're trying to get work done. [3]

My breaking point is actually the idea of using dub to call the system package manager, which I still think is a Really Bad Idea. [4]

-Wyatt

[0] Consider the output of perl '-V:.*site.*' and the existence of Perlbrew (http://perlbrew.pl/)
[1] As a tangent, a nice separate utility to have might be something like a "dub-config" to help with module paths and maybe linkage (In the vein of all those /usr/bin/*-config things).  Like so: dmd `dub-config --moddir vibed` thisLinksVibe.d.
[2] http://www.gentoo.org/proj/en/perl/g-cpan.xml
[3] Yes, juvenile RHELL potshots make me feel a little better about my situation.
[4] https://github.com/rejectedsoftware/dub/issues/52