Am 02.02.2015 um 10:44 schrieb Andrej Mitrovic:
On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote:
snip
Also:
- Dub installs everything in ~/ (home, which on Windows is an awful
location anywho). It's a pain in the ass for browsing dependencies in
your editor. If it's just a submodule you can easily view it in the
source tree (e.g. just open ./submodules/).
There is a request to make this configurable and it's a rather trivial
addition. I just don't have the time to implement all feature requests
myself, which is basically why it is not implemented, yet.
However, you are free to instead put the packages wherever you want
instead and use "dub add-path" (or "add-local") to register it with DUB.
You will just have to manually fetch the sources in this case.
You are also free to use git submodules and use a path based dependency
to force using that particular instance of a package. The only caveat is
that this will not work for public packages because there is no straight
forward way to handle submodules properly when GitHub et al. are involved.
- By default dub emits internal stack traces. This is an insane amount
of visual noise that I don't want to read.
If this is true for a certain error message, please submit a ticket (or
better yet, a quick pull request). Stack traces are supposed to be
emitted only when the -v or --vverbose command line switches are present.
- If I want to try a new version of a dependency, I have to change the
damn .json package file instead of doing a simple 'git checkout ...'.
What's worse, I have to wait 15-20 minutes for the latest tagged version
of a dependency to finally show up on code.dlang.org.
I don't get this. You'd usually use something like `"somedep":
"~>1.0.0"` in your dub.json. Whenever you then run "dub upgrade", it
will update to the latest matching version.
Regarding the update frequency of the package registry, as the package
maintainer you can often speed this up considerably by pressing the
manual update button on the package management page. It would be better
to use GitHub's hooks functionality to get instant updates, but that
requires quite some more work, as well as registering each repository
with the registry (using OAuth).
I could use add-local, but it's broken[1].
I didn't notice that thread, but did you try the most recent version?
There are sub module related fixes in both 0.9.22 and on GIT master that
could affect this.
- Shit breaks every N releases (where N is arbitrary). As if it's not
enough that code tends to break between compiler releases, so do
packages between DUB releases. Something that used to build half a year
ago no longer does.
We need more regression tests in the test suite, that's true. Going by
the relative shortage of development resources, it would be helpful to
get some feedback on such regressions, so that they get some extra
priority. Right now I have barely enough time to fix issues or add
important features, so a strict regression suite policy as for DMD
unfortunately is just not realistic ATM.
I don't recall when was the last time an RDMD or Make update has ever
broken my projects.
- I'm not a fan of poorly tested software, and DUB falls into that
category.
I've complained before about Git submodules being a bit broken on
Windows, maybe this was fixed in the meantime. It works solidly on
Linux, and I'm making the decision to transfer all my projects that use
dependencies to using submodules instead.
The bottom line is, time spent on dealing with package management bugs
is completely wasted developer time.
[1]:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/5280/
