www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Examples of dub use needed

reply Guido <guido mailinator.org> writes:
Dub doesn't really work like other package managers. When I load 
a package:

dub fetch scriptlike

It stores it someplace and doesn't say where. You have to run 
'dub list' to figure out where. That's is very different than 
other packages. It deserves a bigger mention in the meager 
documentation.

I've been trying to init a project using the command

dub -init -f sdl trickproject
-or-
dub -f sdl -init trickproject

and nothing seems to parse.

So, I look at the source code for the format option and see this:
args.getopt("f|format", &m_format, [
     "Sets the format to use for the package description file. 
Possible values:",
     "  " ~ [__traits(allMembers, PackageFormat)].map!(f => f == 
m_format.init.to!string ? f ~ " (default)" : f).join(", ")
]);

It doesn't look straightforward at all. Not sure why there is so 
much complexity on this particular commandline option, but 
shouldn't these command options work the way I have them?

In the interactive mode, I get to make the selection for the 
project file format. I don't see many examples of how to use 
options.
Jun 20 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-06-21 06:42, Guido wrote:

 Dub doesn't really work like other package managers. When I load a package:

 dub fetch scriptlike

 It stores it someplace and doesn't say where. You have to run 'dub list'
 to figure out where. That's is very different than other packages. It
 deserves a bigger mention in the meager documentation.


Dub doesn't install packages. It's not a tool meant for end users. If 
you want something installed in the traditional sense it should go in 
the system package manager.


 I've been trying to init a project using the command

 dub -init -f sdl trickproject
 -or-
 dub -f sdl -init trickproject

 and nothing seems to parse.


The correct way is:

dub init trickproject -f sdl

Note that "init" is a command and not a flag. You can run "dub --help" 
to see the "init" command. The run "dub init --help" to see that help 
for that specific command.

-- 
/Jacob Carlborg
Jun 20 2016
parent reply poliklosio <poliklosio happypizza.com> writes:
On Tuesday, 21 June 2016 at 06:30:11 UTC, Jacob Carlborg wrote:

 On 2016-06-21 06:42, Guido wrote:

 Dub doesn't really work like other package managers. When I 
 load a package:

 dub fetch scriptlike

 It stores it someplace and doesn't say where. You have to run 
 'dub list'
 to figure out where. That's is very different than other 
 packages. It
 deserves a bigger mention in the meager documentation.


 Dub doesn't install packages. It's not a tool meant for end 
 users. If you want something installed in the traditional sense 
 it should go in the system package manager.


Wow, really?
Then what is the fetch command for? I started using dub a 
recently (2 months ago) and totally didn't notice that there is 
any other purpose of the fetch command. I even installed dcd, 
dfmt and dscanner through dub fetch, only to find out these were 
older versions which didn't work.
So what is the purpose of dub fetch?
Jun 21 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 June 2016 at 07:24:33 UTC, poliklosio wrote:


 Wow, really?
 Then what is the fetch command for? I started using dub a 
 recently (2 months ago) and totally didn't notice that there is 
 any other purpose of the fetch command. I even installed dcd, 
 dfmt and dscanner through dub fetch, only to find out these 
 were older versions which didn't work.
 So what is the purpose of dub fetch?


One use case is to bypass dub's global package cache for specific 
projects. For example, say you're making something using 
DerelictGL3 and DerelictGLFW3, you could do this:

mkdir derelict
cd derelict
dub fetch --cache=local derelict-glfw3 --version=2.0.0
dub fetch --cache=local derelict-gl3 --version=1.0.18
dub fetch --cache=local derelict-util --version=2.0.4

If you need the libraries for a project that isn't using DUB, you 
can then do this:

dub add-local derelict-util-2.0.4
cd derelict-glfw3-2.0.0
dub build -brelease
cd ../derelict-gl3-1.0.18
dub build -brelease
cd ../derelict-util-2.0.4
dub build -brelease

The first line allows derelict-glfw3 and derelict-gl3 to find 
derelict-util when you are building them.

You can use all of the packages with other dub managed projects 
by just using add-local on each of them and not bothering with 
building any of them.

dub add-local derelict-util-2.0.4
dub add-local derelict-glfw3-2.0.0
dub add-local derelict-gl3-1.0.18

DUB will prefer these over the global cache if they are already 
there. This is useful for making changes to the libraries 
yourself and having them show up in other projects that depend on 
them. You certainly don't want to modify the files in the global 
cache. And if you checkout from git directly, you'd have to 
modify the DUB configuration of any projects you want to make use 
of your changes so that they use paths for their dependencies 
rather than versions. dub fetch + dub add-local is so much 
simpler. A
Jun 21 2016
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 June 2016 at 07:44:14 UTC, Mike Parker wrote:


 global cache. And if you checkout from git directly, you'd have 
 to modify the DUB configuration of any projects you want to 
 make use of your changes so that they use paths for their 
 dependencies rather than versions. dub fetch + dub add-local is 
 so much simpler. A


Although, I forgot about dub add-override, which allows you to 
specify a path and version number for a package to be preferred 
over something in the global cache. Using that with git clone 
actually looks to be just as easy as dub fetch/dub add-local, and 
is probably better if you want to submit PRs.
Jun 21 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On 06/21/2016 10:24 AM, poliklosio wrote:

 Wow, really?
 Then what is the fetch command for? I started using dub a recently (2
 months ago) and totally didn't notice that there is any other purpose of
 the fetch command. I even installed dcd, dfmt and dscanner through dub
 fetch, only to find out these were older versions which didn't work.
 So what is the purpose of dub fetch?


Apart from `--cache=local` version, one of intended use case is to get
various small utility tools needed only during development and not
needing to be distributed to the end user, like dfmt. After `dub fetch
dfmt` one can run `dub run dfmt <args>` to invoke such tool without
knowing where dub cache is located.

But it is indeed supposed to be rare case and I do recommend to install
such tools via system package manager instead whenever possible. So yes,
you don't need `dub fetch` at all for most part.
Jun 21 2016
next sibling parent reply Guido <guido mailinator.org> writes:
On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:

 On 06/21/2016 10:24 AM, poliklosio wrote:

 Wow, really?
 Then what is the fetch command for? I started using dub a 
 recently (2
 months ago) and totally didn't notice that there is any other 
 purpose of
 the fetch command. I even installed dcd, dfmt and dscanner 
 through dub
 fetch, only to find out these were older versions which didn't 
 work.
 So what is the purpose of dub fetch?


 Apart from `--cache=local` version, one of intended use case is 
 to get various small utility tools needed only during 
 development and not needing to be distributed to the end user, 
 like dfmt. After `dub fetch dfmt` one can run `dub run dfmt 
 <args>` to invoke such tool without knowing where dub cache is 
 located.

 But it is indeed supposed to be rare case and I do recommend to 
 install such tools via system package manager instead whenever 
 possible. So yes, you don't need `dub fetch` at all for most 
 part.


Thanks for the replies. This really clears things up.

I'm the sort of person who learns by example, and what I was 
saying is that there aren't enough examples online of how dub is 
used in a practical setting.

I'm also the sort of person who doesn't trust toolchains that 
need to download things every time from the internet just to 
compile. Is this what dub is doing? In other words, when a 
project is built using dub, does it use the local cache from the 
last build by default, check for later versions, pull things from 
the internet, etc? Or do I need -cache=local for that?
Jun 21 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 June 2016 at 15:02:01 UTC, Guido wrote:


 I'm the sort of person who learns by example, and what I was 
 saying is that there aren't enough examples online of how dub 
 is used in a practical setting.


There aren't that many commands for DUB on the command line. Most 
of what you need can be gleaned from dub --help, but there is 
also documentation online [1]. For package configurations, the 
documentation at code.dlang.org covers everything [2] & [3], just 
not always clearly. It's easy enough to get examples for that 
from all of the projects listed in the registry [4]. Just click 
through them to their github or bitbucket repositories and study 
their dub.json/sdl files. And there's always the DUB forums [5.


 I'm also the sort of person who doesn't trust toolchains that 
 need to download things every time from the internet just to 
 compile. Is this what dub is doing? In other words, when a 
 project is built using dub, does it use the local cache from 
 the last build by default, check for later versions, pull 
 things from the internet, etc? Or do I need -cache=local for 
 that?


DUB only downloads a package when it first needs it. It will only 
update to a newer version for a given project if you run 'dub 
upgrade' on that project. Given a project foo which relies on DUB 
package libbar 1.0.0:

cd foo
dub build <-- checks if libbar 1.0.0 is in the cache, finds it 
missing, downloads it
dub build <-- checks if libbar 1.0.0 is in the cache, finds it
dub upgrade <-- checks if the latest version is in the cache. If 
not, downloads it
                 according to how you have specified your 
dependency (see [6])


[1] 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
[2] https://code.dlang.org/package-format?lang=json
[3] https://code.dlang.org/package-format?lang=sdl
[4] https://code.dlang.org/
[5] http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
[6] https://github.com/dlang/dub/wiki/Version-management
Jun 21 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 June 2016 at 01:56:34 UTC, Mike Parker wrote:

 There aren't that many commands for DUB on the command line. 
 Most of what you need can be gleaned from dub --help, but there 
 is also documentation online [1]. For package configurations, 
 the documentation at code.dlang.org covers everything [2] & 
 [3], just not always clearly. It's easy enough to get examples 
 for that from all of the projects listed in the registry [4]. 
 Just click through them to their github or bitbucket 
 repositories and study their dub.json/sdl files. And there's 
 always the DUB forums [5.


Given that this project is going to bundled with DMD some time in 
the future, I think that this response sees the forest for the 
trees. While those things would make the OPs life a little 
easier, hopefully, the number of people using dub would increase 
with its inclusion in DMD. I care more about ease of use for all 
the people who might start using dub in the future. Not all of 
these people would want to learn from dub --help.  I don't think 
I'm alone in believing that the dub documentation could be 
improved, especially with tutorials or examples.
Jun 22 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 22 June 2016 at 13:51:55 UTC, jmh530 wrote:


 Given that this project is going to bundled with DMD some time 
 in the future, I think that this response sees the forest for 
 the trees. While those things would make the OPs life a little 
 easier, hopefully, the number of people using dub would 
 increase with its inclusion in DMD. I care more about ease of 
 use for all the people who might start using dub in the future. 
 Not all of these people would want to learn from dub --help.  I 
 don't think I'm alone in believing that the dub documentation 
 could be improved, especially with tutorials or examples.


I just see things from the perspective that I learned everything 
I needed from dub --help and the documentation that *is* online. 
The forums are linked in the menu item 'About' next to 
'Documentation' at the top of code.dlang.org. All the information 
is there. Sure, it could probably clearer in some places, but it 
does exist and it is usable today. What needs to be improved?
Jun 22 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 June 2016 at 15:48:03 UTC, Mike Parker wrote:

 What needs to be improved?


I will say that it looks a lot better now than it used to, even 
though I'm not sure if the content has changed as much.

It's not entirely clear why to use SDLang over JSON. It should be 
more clearly labeled which is preferred.



In the JSON description, I'm not a fan of the Build Options text. 
I would change it to this:

Build settings influence the command line options passed to the 
compiler and linker. All settings are optional. Examples:

{
	"versions": ["PrintfDebugging", "UseAmd64Impl"],
	"dflags": ["-vtls"],
	"sourceFiles": ["lib/mylib.lib"],
}

In addition, it is possible to implement platform specific 
settings using field name suffixes. Field name suffixes are dash 
separated platform identifiers, as defined in the D language 
reference, but converted to lower case. The order of these 
suffixes is os-architecture-compiler, where any of these parts 
can be left off. For instance, "sourceFiles-windows-x86_64-dmd" 
would pass "sourceFiles" only to the DMD compiler on Windows with 
an x86_64 bit architecture. This can be helpful when a project 
requires libraries specific to a particular OS and hardware 
architecture. Other examples:

{
	"versions": ["PrintfDebugging"],
	"dflags-dmd": ["-vtls"],
	"versions-x86_64": ["UseAmd64Impl"]
	"libs-posix": ["ssl", "crypto"],
	"sourceFiles-windows-x86_64-dmd": ["lib/win32/mylib.lib"],
}
____________________
In the Configuration section:
It says "A list of platform suffixes (as used for the build 
settings) to limit on which platforms the configuration applies." 
Platform suffixes is not clear enough. Above they are referred to 
as field name suffixes. I would re-write this as "A list of field 
name suffixes (as described above and used for the build 
settings) to limit on which platforms the configuration applies. 
For instance, setting "platforms": ["windows-x86_64-dmd"] would 
mean the configuration would only apply when compiling only with 
the DMD compiler on Windows with an x86_64 bit architecture."

Also, it says "When defining a configuration's platform, any of 
the suffixes described in build settings may be combined to make 
the configuration as specific as necessary." to which I would 
append:

For instance, in the following configuration
{
	"name": "desktop-app",
	"targetType": "executable",
	"platforms": ["windows"],
	"versions": ["DesktopApp"],
	"libs-x86_64-dmd": ["d3d9"]
},
"libs" is customized for compiling with DMD on the x86_64 
architecture.  Further, since "platforms" is set to Windows, it 
applies "libs" (and "versions" and "windows" does not need to be 
specified.
Jun 22 2016
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 22 June 2016 at 15:48:03 UTC, Mike Parker wrote:


 I just see things from the perspective that I learned 
 everything I needed from dub --help and the documentation that 
 *is* online. The forums are linked in the menu item 'About' 
 next to 'Documentation' at the top of code.dlang.org. All the 
 information is there. Sure, it could probably clearer in some 
 places, but it does exist and it is usable today. What needs to 
 be improved?


Suppose you need to link against a .so file that is in another 
directory. How do you find out how to do that on this page:
http://code.dlang.org/package-format?lang=json

But that's just one case. There are basically no examples at all 
(and the ones that are there probably don't help). There's not 
even a good explanation of what Dub is. Rust, on the other hand, 
offers this: http://doc.crates.io/guide.html

Rust offers something professional that helps you get going 
quickly (hasn't there been talk about the first five minutes?), D 
pushes people away from the language. I will not touch Dub 
because I can't tell others that they should figure out how to 
use it by looking at the insides of existing packages and then 
fiddling around with various configurations to see if they can 
get it to work.

This is not to criticize anyone's work. But it is to say that 
there is no way Dub, with its current documentation, should be 
distributed with DMD.
Jun 22 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 June 2016 at 19:00:56 UTC, bachmeier wrote:

 I will not touch Dub because I can't tell others that they 
 should figure out how to use it by looking at the insides of 
 existing packages and then fiddling around with various 
 configurations to see if they can get it to work.


I will touch dub, but I still felt like shouting "well then why 
doesn't the next edition of Learning D just tell people to look 
at some D source code and figure it out" when I saw that...

I think dub is a great project; it just needs a some work on 
docs/examples/tutorials if it is going to get included with DMD.
Jun 22 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 22 June 2016 at 19:20:30 UTC, jmh530 wrote:


 I will touch dub, but I still felt like shouting "well then why 
 doesn't the next edition of Learning D just tell people to look 
 at some D source code and figure it out" when I saw that...


What are you referring to?


 I think dub is a great project; it just needs a some work on 
 docs/examples/tutorials if it is going to get included with DMD.


Then pitch in! There are already several examples in the DUB 
repository. If you think there should be more, create an issue. 
If you find documentation missing, report it. I wouldn't imagine 
the Sönke by himself can think of every conceivable scenario 
someone might need info on, or where the documentation isn't 
clear enough. Things can't improve unless people let the 
maintainer know what is missing and, if possible, contribute it 
themselves.
Jun 22 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
FWIW, this thread has inspired me to begin work on a project I've 
titled 'The DUB Handbook'. I've been meaning to write some 
tutorials about DUB (among other things) for learningd.org, but I 
think a detailed guide would be a more worthwhile project to 
pursue.

My intention with the text is to provide a detailed description 
of every dub command and configuration directive, along with 
examples of how to use them in both JSON and SDLang formats. I've 
spent an hour getting it set up today (I'm using gitbook) and 
expect to be working on it over the next several weeks. When it's 
ready for feedback, I'll make it publicly available and announce 
it here in the forums. I plan to release it under a CC license.
Jun 23 2016
next sibling parent reply Guido <guido mailinator.org> writes:
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote:

 FWIW, this thread has inspired me to begin work on a project 
 I've titled 'The DUB Handbook'. I've been meaning to write some 
 tutorials about DUB (among other things) for learningd.org, but 
 I think a detailed guide would be a more worthwhile project to 
 pursue.

 My intention with the text is to provide a detailed description 
 of every dub command and configuration directive, along with 
 examples of how to use them in both JSON and SDLang formats. 
 I've spent an hour getting it set up today (I'm using gitbook) 
 and expect to be working on it over the next several weeks. 
 When it's ready for feedback, I'll make it publicly available 
 and announce it here in the forums. I plan to release it under 
 a CC license.


Like I said, thanks for clearing things up.

But I have to say that more detailed descriptions of commands is 
not what I had in mind. What are the best coding practices and 
why?

I obviously haven't started using dub yet, so I won't be able to 
judge whether a code example is merely adequate or very robust. 
For example, why subpackages? It's in there for a reason; what 
situations call for subpackages? Why use -ddoxFilterArgs? When & 
how to static link? What dub-based project does a good job 
building for multiple platforms?

 From what's been discussed, I should always specify version 
number. Is there some best practice for flagging when a change to 
dependencies breaks your code? I would create a build type that 
lists the latest version of each dependency & run unittests. Is 
there a better way that someone is using in the field?

Right now, I'm going around trying to steal the best coding 
practices, and I only want to steal from the best.
Jun 23 2016
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 23 June 2016 at 13:31:37 UTC, Guido wrote:


 But I have to say that more detailed descriptions of commands 
 is not what I had in mind. What are the best coding practices 
 and why?

 I obviously haven't started using dub yet, so I won't be able 
 to judge whether a code example is merely adequate or very 
 robust. For example, why subpackages? It's in there for a 
 reason; what situations call for subpackages? Why use 
 -ddoxFilterArgs? When & how to static link? What dub-based 
 project does a good job building for multiple platforms?

 From what's been discussed, I should always specify version 
 number. Is there some best practice for flagging when a change 
 to dependencies breaks your code? I would create a build type 
 that lists the latest version of each dependency & run 
 unittests. Is there a better way that someone is using in the 
 field?


It wouldn't be much of a handbook if it didn't cover usage. Of 
course I will give examples, with tips based on how I use it and 
any I can gather from other users. Once I make it available for 
feedback, feel free to suggest anything you feel is missing.
Jun 23 2016
prev sibling next sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote:

 My intention with the text is to provide a detailed description 
 of every dub command and configuration directive, along with 
 examples of how to use them in both JSON and SDLang formats.


Yes, this is a good idea.  It took me most of a day of trying to 
wrestle my project into a dub-compatible state and I honestly 
ended up giving up because my old Makefile is shorter, faster, 
and much easier to understand. (IIRC, the last straw was 
realising dub doesn't seem to have a good answer to Make targets, 
so building my library test samples was... impossible?  Or at 
least completely obtuse.)

I would request that you especially look for common build idioms 
and how to represent them in dub, because I'm apparently not the 
only one who thinks it's not obvious.

-Wyatt
Jun 23 2016
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 23 June 2016 at 13:33:03 UTC, Wyatt wrote:


 Yes, this is a good idea.  It took me most of a day of trying 
 to wrestle my project into a dub-compatible state and I 
 honestly ended up giving up because my old Makefile is shorter, 
 faster, and much easier to understand. (IIRC, the last straw 
 was realising dub doesn't seem to have a good answer to Make 
 targets, so building my library test samples was... impossible?
  Or at least completely obtuse.)


Makefiles that are easier to understand? Ugh. I hate Makefiles 
with a passion. For me, DUB is so much more intuitive. Testing a 
library as you develop it is straightforward. I'll certainly 
cover that. I'm not sure what you mean about the make targets, 
though. DUB does have configurations, which are approximately the 
same thing.


 I would request that you especially look for common build 
 idioms and how to represent them in dub, because I'm apparently 
 not the only one who thinks it's not obvious.


Sure, I'll do what I can.
Jun 23 2016
prev sibling parent WhatMeForget <kheaser gmail.com> writes:
On Thursday, 23 June 2016 at 07:46:41 UTC, Mike Parker wrote:

 FWIW, this thread has inspired me to begin work on a project 
 I've titled 'The DUB Handbook'. I've been meaning to write some 
 tutorials about DUB (among other things) for learningd.org, but 
 I think a detailed guide would be a more worthwhile project to 
 pursue.

 My intention with the text is to provide a detailed description 
 of every dub command and configuration directive, along with 
 examples of how to use them in both JSON and SDLang formats. 
 I've spent an hour getting it set up today (I'm using gitbook) 
 and expect to be working on it over the next several weeks. 
 When it's ready for feedback, I'll make it publicly available 
 and announce it here in the forums. I plan to release it under 
 a CC license.


I've been trying to get my head around DUB for a long time. And 
that is even after buying D Web Development and your Learning D. 
I would be very interested in providing feedback.  I believe it 
would be very helpful to provide comprehensive "walk throughs" of 
the most useful and important scenarios. Include windows and 
Linux since their path layouts differ. Maybe even seed DUB's D 
Package Registry with a little tutorial package that could be 
used them.

And also throw in some definitions: what is actually meant by 
"cache", local, dependencies (is this imported source files or 
libraries needed during linking, or something else)

For instance, I installed DUB and some packages on a laptop 
(running Linux) about a week ago and then left it alone.  I'm now 
back in a terminal and it's like I've completely forgotten 
everything: I see the directories under ~/.dub but I can't seem 
to get dub list, dub fetch, or dub run  to work?

Anyway, sorry to ramble. Thank you for Handbook.
Jun 23 2016
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 23 June 2016 at 01:43:32 UTC, Mike Parker wrote:

 On Wednesday, 22 June 2016 at 19:20:30 UTC, jmh530 wrote:


 I will touch dub, but I still felt like shouting "well then 
 why doesn't the next edition of Learning D just tell people to 
 look at some D source code and figure it out" when I saw 
 that...


 What are you referring to?


My point was that I don't consider this advice for everyone. I 
already know how to use dub. I recommend improving the docs so 
that someone else doesn't have the pain points that I had when I 
was trying to figure it out.

You had recommended looking through json/sdl files from existing 
projects to learn how to use dub properly. If someone took this 
advice for learning D, it would be to look at source code in 
random projects to try to understand the language. I've got your 
Learning D book on my bookshelf. It doesn't just have one line 
that says, hey just look at some source code and figure it out. 
It breaks things apart into small examples so that you can easily 
process each part.


 Then pitch in!


I put a few changes I would make to the docs on this thread.
Jun 23 2016
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 23 June 2016 at 15:03:20 UTC, jmh530 wrote:

 You had recommended looking through json/sdl files from 
 existing projects to learn how to use dub properly. If someone 
 took this advice for learning D, it would be to look at source 
 code in random projects to try to understand the language. I've 
 got your Learning D book on my bookshelf. It doesn't just have 
 one line that says, hey just look at some source code and 
 figure it out. It breaks things apart into small examples so 
 that you can easily process each part.


I mentioned it as one of *six* resources. That does not at all 
imply that I was suggesting it be the only way to learn DUB. You 
yourself said in a subsequent post that you would like to see 
more examples. What better examples than real world projects? 
Checking out open source projects has always been a valuable way 
to learn different aspects of software development ('Use the 
source, Luke' is a common expression), including languages, but 
of course it isn't the only way.
Jun 23 2016
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Wednesday, 22 June 2016 at 19:00:56 UTC, bachmeier wrote:

 On Wednesday, 22 June 2016 at 15:48:03 UTC, Mike Parker wrote:



 Suppose you need to link against a .so file that is in another 
 directory. How do you find out how to do that on this page:
 http://code.dlang.org/package-format?lang=json

 But that's just one case. There are basically no examples at 
 all (and the ones that are there probably don't help). There's 
 not even a good explanation of what Dub is. Rust, on the other 
 hand, offers this: http://doc.crates.io/guide.html


If there's no dub option for it, then wouldn't you just pass it 
to the compiler in a dflags directive? That's basic compiler 
usage, is it not?


 This is not to criticize anyone's work. But it is to say that 
 there is no way Dub, with its current documentation, should be 
 distributed with DMD.


Then why not pitch in to help improving the documentation? If you 
think there should be something explaining how to find shared 
libraries in another directory and can't find it anywhere, you 
can go to the DUB issues page and report it, or ask in the DUB 
forums how to contribute. That's how things get better around 
here.
Jun 22 2016
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 22 June 2016 at 01:56:34 UTC, Mike Parker wrote:

 And there's always the DUB forums [5.


I didn't even know there were DUB forums.
Jun 22 2016
prev sibling parent reply poliklosio <poliklosio happypizza.com> writes:
On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:

 But it is indeed supposed to be rare case and I do recommend to 
 install such tools via system package manager instead whenever 
 possible. So yes, you don't need `dub fetch` at all for most 
 part.


Yes, it is best not to interfere with system package managers if 
they exist. On the other hand how do you install end-user tools 
like dcd, dfmt on windows, other than git clone + build?

I'm wondering why are packages updated so rarely on the dub 
repository?
For example I have dfmt 0.5.0, while dub fetch installs 0.4.5
Jun 21 2016
parent ZombineDev <petar.p.kirov gmail.com> writes:
On Tuesday, 21 June 2016 at 20:38:05 UTC, poliklosio wrote:

 On Tuesday, 21 June 2016 at 08:58:59 UTC, Dicebot wrote:

 But it is indeed supposed to be rare case and I do recommend 
 to install such tools via system package manager instead 
 whenever possible. So yes, you don't need `dub fetch` at all 
 for most part.


 Yes, it is best not to interfere with system package managers 
 if they exist. On the other hand how do you install end-user 
 tools like dcd, dfmt on windows, other than git clone + build?

 I'm wondering why are packages updated so rarely on the dub 
 repository?
 For example I have dfmt 0.5.0, while dub fetch installs 0.4.5


`dub fetch` downloads the latest stable version if the 
`--version=` option is not specified. dfmt 0.5.0 is still in 
beta, according to latest tag in the repository.
`dub search` on the other hand lists only the latest version, so 
you can use that (in combination with `dub fetch --version=`) to 
get the latest version.
Jun 21 2016
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 June 2016 at 04:42:39 UTC, Guido wrote:

 Dub doesn't really work like other package managers. When I 
 load a package:

 dub fetch scriptlike

 It stores it someplace and doesn't say where. You have to run 
 'dub list' to figure out where. That's is very different than 
 other packages. It deserves a bigger mention in the meager 
 documentation.


DUB is not a general-purpose package manager. It's a build tool 
that knows how to manage your package dependencies. Assuming you 
are using DUB to manage a project that uses scriptlike, and you 
have scriptlike configured as a dependency, you do *not* need to 
run dub fetch. When you build your project, DUB will download and 
compile scriptlike for you, make sure its source modules are on 
your import path, and that it is linked with your executable.

In all the years I've used dub, the only time I've cared about 
where its cache is located was when I wanted to zap everything in 
it in one go. By default, on Windows, it's currently the roaming 
appdata directory (though that is likely to change to the local 
appdata dir in a future version), which on Windows 10 is:

C:\Users\User Name\AppData\Roaming\dub

On other systems it should be:

~/.dub

Again, just forget it exists. If you need to worry about 
modifying cached packages or pulling the static libraries out or 
whatever, use dub fetch --cache=local like I described above.
Jun 21 2016
prev sibling next sibling parent =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 21.06.2016 um 06:42 schrieb Guido:

 Dub doesn't really work like other package managers. When I load a package:

 dub fetch scriptlike

 It stores it someplace and doesn't say where. You have to run 'dub list'
 to figure out where. That's is very different than other packages. It
 deserves a bigger mention in the meager documentation.

 I've been trying to init a project using the command

 dub -init -f sdl trickproject
 -or-
 dub -f sdl -init trickproject


It must be "dub init -f sdl", without the dash in front of "init". 
Otherwise it looks correct.


 and nothing seems to parse.

 So, I look at the source code for the format option and see this:
 args.getopt("f|format", &m_format, [
      "Sets the format to use for the package description file. Possible
 values:",
      "  " ~ [__traits(allMembers, PackageFormat)].map!(f => f ==
 m_format.init.to!string ? f ~ " (default)" : f).join(", ")
 ]);

 It doesn't look straightforward at all. Not sure why there is so much
 complexity on this particular commandline option, but shouldn't these
 command options work the way I have them?


The complexity just comes from dynamically determining the default file 
format (to avoid it getting out of sync).
Jun 21 2016
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 21 June 2016 at 04:42:39 UTC, Guido wrote:

 It deserves a bigger mention in the meager documentation.
 


IMHO, Dub 1.0 should have done a bit more work on the 
documentation.
Jun 21 2016