On 6/4/15 3:49 PM, ponce wrote:
> On Thursday, 4 June 2015 at 15:07:58 UTC, Sönke Ludwig wrote:
>> Am 04.06.2015 um 15:07 schrieb Steven Schveighoffer:
>>> This would be better, but I still think a way to add dependencies should
>>> be supported on the command line. Something like dub depend someproject.
>>> You don't always know what a project will need at the beginning.
>
> imho if a program consumes a particular configuration file, it should
> not also write it.
> Counter examples: Visual Studio projects, MFC, IRC bouncers, and other
> technologies from Hell.

That program is not consuming a configuration file, it's editing it. Call it dub-depend if you want.

-Steve

On 2015-06-04 19:44, Steven Schveighoffer wrote:

> The use case I'm thinking of is basically:
>
> import somepackage.somemodule;
> ...
>
> compile -> can't find somepackage.somemodule.
> did you mean somepackage.somemodule from libgeneric on code.dlang.org?
>     (url)
>     to add: dub depend add libgeneric
>
> dub depend add libgeneric => found it, added it, added dependency
>
> I don't have to look up anything on code.dlang.org, I don't have to do
> anything, dub figures it all out from the description file online.

Sounds like a nice feature but how would that work in practice? I mean, there's nothing that connects a particular D module or package to a particular Dub package.

-- 
/Jacob Carlborg

On Thursday, 4 June 2015 at 13:47:41 UTC, Sönke Ludwig wrote:
> A branch *is* an exact version as far as DUB goes (just one that changes over time).

Well, that's the problem then.

> But to make use of any commit relationships within a branch, it would have to gain specific knowledge of GIT or other version management systems.
>
> Adding support for commit hashes in dub.selections.json is still TBD, but would be another alternative.

I'd say it's the only consistent way.

>
> BTW, my primary concern with all of these things is retaining a healthy public package eco system. I personally suspect that this is much more important for the language as a whole rather than pleasing every single taste. This doesn't mean that the latter isn't a worthwhile goal, but to me the former has always been more important. What is missing is a proposal how to solve both issues at the same time.

I can understand that. But from what I've seen with rubygems, it is not a problem in practice. You're totally right that released packages shouldn't have such dependencies. A warning message in dub or a check on code.dlang.org is totally okay IMO.

> For example for conflict resolution. This is the foremost reason why the *have* to be banned from dub.json. You can't really know if a branch matches/is compatible with any particular version (range) or another branch, so you have to either make an arbitrary guess (always prefer the branch; always prefer the version; always prefer "master", but a tagged version otherwise; etc.), or always issue a version conflict error.

Definitely always prefer the branch. The goal is to let the developer override the decisions made by upstream library authors.

>
> The practical effect that was already very visible in the existing ecosystem was that packages tended to separate into two clusters. One cluster that used branch dependencies and another that used version dependencies. Both incompatible with each other. It also meant that a lot of people didn't bother to make any version tags at all, which is understandable, but also a very bad influence to the stability of the ecosystem. Semantic versioning, if used correctly, is a very important factor in that regard.

Yes, but that's a social problem. We can nudge people in the right direction by printing a warning message, or even by rejecting it completely on code.dlang.org.

>
> The compromise solution to allow branch based dependencies only in the version selection file doesn't really have drawbacks, but dodges all of those issues by moving the decision to the root of the dependency tree.

I does have obvious drawbacks: If dub.selections.json contains non-exact versions, different developers can get slightly different dependencies. dub.selections.json must fully determine the versions that are going to be used, otherwise it has failed its purpose.

>
>>
>>>
>>> You can also check out certain branches locally and use "dub
>>> add-local" or "dub add-path" to let DUB use it instead of the publicly
>>> registered one.
>>
>> This is not an option in a larger team. Everyone would have to do that
>> manually, or you'd need to write a custom script to do what is actually
>> the package manager's task.
>
> Using dub.selections.json should be the right tool then.

As explained above, it isn't.

> You could of course also use things like git submodules + path based dependencies in this case, there is no need to force everything into one schema (especially when it doesn't fit well, such as versions and branches).

Yes, and I'm sure I can come up with even more workarounds ;-)

On 6/5/15 5:07 AM, Jacob Carlborg wrote:
> On 2015-06-04 19:44, Steven Schveighoffer wrote:
>
>> The use case I'm thinking of is basically:
>>
>> import somepackage.somemodule;
>> ...
>>
>> compile -> can't find somepackage.somemodule.
>> did you mean somepackage.somemodule from libgeneric on code.dlang.org?
>>     (url)
>>     to add: dub depend add libgeneric
>>
>> dub depend add libgeneric => found it, added it, added dependency
>>
>> I don't have to look up anything on code.dlang.org, I don't have to do
>> anything, dub figures it all out from the description file online.
>
> Sounds like a nice feature but how would that work in practice? I mean,
> there's nothing that connects a particular D module or package to a
> particular Dub package.
>

The source of the package does. code.dlang.org can create this automatically.

-Steve

On 06/01/2015 02:20 AM, Nick Sabalausky wrote:
> On 05/31/2015 11:48 PM, Manu via Digitalmars-d wrote:
>>
>> As for dub, I'd use it if it worked like a package manager; dub get
>> libcurl-d libqt-d zlib-d libsdl2-d etc
>> I have no use for it as a build system, and therefore it's expression
>> of dependencies is no use to me. I just want something that works the
>> same way as '-dev' packages already work perfectly well in linux, that
>> is, they fetch headers and libs, and put them in a standard location
>> that all the tooling can find.
>>
>
> Ditto. Dub's great if you let it be your buildsystem, but as soon as you
> want to use it as a package-manager-only it becomes an uphill battle
> with dub fighting back every step of the way (I speak from experience).
> That problem is worse if your project is a library that you want
> fetchable through dub.
>
> That's why I've been working on some PRs to fix all that. The first step
> is here (building/expanding on a flag another contributer recently added):
>
> https://github.com/D-Programming-Language/dub/pull/572
>
> (Although I think I may need to change --data=libs and separate system
> libs from dependency libs since linkers expect those to be passed in
> differently.)
>
> The next step will be to add a flag to have that data get output in a
> compiler-ready argument list (your choice of compiler, of course).
> That'll let you do something comparable to "pkg-config --cflags --libs".
>

All the above is now included in the PR:

https://github.com/D-Programming-Language/dub/pull/572

Working example:

------------------------------
$ cd /home/nick/proj/dub

$ dub describe --data=main-source-file --data=options \
--data=versions --data=import-paths
'/home/nick/proj/dub/source/app.d' -debug -g -w -version=DubUseCurl -version=Have_dub '-I/home/nick/proj/dub/source/'

$ dub describe --compiler=ldc --data=options --data=versions
-d-debug -g -w -oq -od=.dub/obj -oq -od=.dub/obj -d-version=DubUseCurl -d-version=Have_dub

$ dub describe --data-list --data=options --data=versions
debugMode
debugInfo
warningsAsErrors

DubUseCurl
Have_dub
------------------------------

Of course, "dub describe --help" for the full list of options.

Only thing not included yet is this:

> Then finally, a shortcut flag so you can just do something kinda like:
>
> rdmd --build-only `dub describe --cmdargs=rdmd` src/main.d
>
> And all your dependencies will be properly referenced (-I..., linker
> flags, etc).
>

On 01/06/2015 04:48, Manu via Digitalmars-d wrote:
> Please declare a standard unix location for D 'includes'. Nobody
> agrees where in the filesystem D files should be.
> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
> before, but it doesn't seem that great), but I want a standard place
> that stuff bundled by linux package managers can agree on.

If you use DUB to build, isn't this transparent anyways?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 06/05/2015 02:56 PM, Bruno Medeiros wrote:
> On 01/06/2015 04:48, Manu via Digitalmars-d wrote:
>> Please declare a standard unix location for D 'includes'. Nobody
>> agrees where in the filesystem D files should be.
>> I use /usr/include/d2/ for my stuff (I saw it precedented a few times
>> before, but it doesn't seem that great), but I want a standard place
>> that stuff bundled by linux package managers can agree on.
>
> If you use DUB to build, isn't this transparent anyways?
>

Yes, but dub's buildsystem isn't always suitable for all projects.

On 06/05/2015 12:45 PM, Nick Sabalausky wrote:
>
> https://github.com/D-Programming-Language/dub/pull/572
>
> Working example:
>
> ------------------------------
> $ cd /home/nick/proj/dub
>
> $ dub describe --data=main-source-file --data=options \
> --data=versions --data=import-paths
> '/home/nick/proj/dub/source/app.d' -debug -g -w -version=DubUseCurl
> -version=Have_dub '-I/home/nick/proj/dub/source/'
>
> $ dub describe --compiler=ldc --data=options --data=versions
> -d-debug -g -w -oq -od=.dub/obj -oq -od=.dub/obj -d-version=DubUseCurl
> -d-version=Have_dub
>
> $ dub describe --data-list --data=options --data=versions
> debugMode
> debugInfo
> warningsAsErrors
>
> DubUseCurl
> Have_dub
> ------------------------------
>

It also works even if your project doesn't have a dub.json :)

$ mkdir ~/my-proj
$ cd ~/my-proj
$ dub fetch vibe-d
$ dub describe vibe-d --data=versions --data=import-paths
-version=VibeLibeventDriver -version=Have_vibe_d -version=Have_libevent -version=Have_openssl '-I/home/nick/.dub/packages/vibe-d-0.7.23-beta.1/source/' '-I/home/nick/.dub/packages/libevent-2.0.1_2.0.16/' '-I/home/nick/.dub/packages/openssl-1.1.4_1.0.1g/'

On 2015-06-05 15:17, Steven Schveighoffer wrote:

> The source of the package does. code.dlang.org can create this
> automatically.

I see two problems with this:

1. Does the registry (code.dlang.org) really know which files a Dub package contains? I would guess the registry mostly contains information where to find the source for a package, i.e. GitHub

Rubygems, for example, on the other hand would be able to do this because a Ruby gem (package) is ZIP archive with all the sources for the package included. Also, when building a gem the package description is "compiled", that is, all shell globs are expanded to locate all files.

2. It's possible to have a file with a completely different module name in D

-- 
/Jacob Carlborg

On 06/06/2015 09:16 AM, Jacob Carlborg wrote:
> On 2015-06-05 15:17, Steven Schveighoffer wrote:
>
>> The source of the package does. code.dlang.org can create this
>> automatically.
>
> I see two problems with this:
>
> 1. Does the registry (code.dlang.org) really know which files a Dub
> package contains? I would guess the registry mostly contains information
> where to find the source for a package, i.e. GitHub
>
> Rubygems, for example, on the other hand would be able to do this
> because a Ruby gem (package) is ZIP archive with all the sources for the
> package included. Also, when building a gem the package description is
> "compiled", that is, all shell globs are expanded to locate all files.
>
> 2. It's possible to have a file with a completely different module name
> in D
>

Even if that stuff isn't currently known to code.dlang.org, it'd all be easy for it to obtain:

$ mkdir some_temp && cd some_temp
$ git clone package_URL dir && cd dir
$ dmd (flags dub already knows) -v | grep import

Would only need to do that when it detects a new version tag (which it already detects).