Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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?
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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
Re: Examples of dub use needed
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 ` 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?
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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", _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).
Re: Examples of dub use needed
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 ` 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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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.
Re: Examples of dub use needed
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
Re: Examples of dub use needed
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?
Re: Examples of dub use needed
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
Examples of dub use needed
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", _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.
