On Mon, 28 Oct 2013 08:32:59 GMT, Stephan Dilly wrote:
On Mon, 28 Oct 2013 09:00:40 +0100, Sönke Ludwig wrote:
Am 27.10.2013 02:14, schrieb Stephan Dilly:
The recently fixed app args bug is biting me. Any chance for a updated release any time soon ?
That problem made me call the package executable myself and made me think.
I like the similarities of dub to npm (nodejs package manager) but what i miss is the ability to simply install a package like "npm forever" and run it via "forever ..." in dub this is more verbose "dub install forever-d" and "dub run forever-d ..." wouldn't it be nice to have a bin folder that dub adds to PATH and move those exe files there so everyone could simply call "forever-d"
Any ideas? Or am i missing something completly?
As Jacob already said, there is some controversy about this topic. On
one hand it would be nice to have something like this, but on the other
hand it opens a lot of questions as soon as you want to go beyond a
single dub-bin directory that is added to PATH (things like resource and
configuration files, OS or distribution specific paths etc.).So the question is if it is a wise idea to implement something now
before knowing how to make a complete solution that fits together will
with the OS package manager, if there is one (and thus possibly being
forced to implement backwards incompatible changes).But a trivial addition would be a less noisy syntax to run application
packages, something like "dubexec forever-d <args>", which translates to
"dub run forever-d --build=release -- <args>"?Yeah, cause now it is really noisy, since I made the mistake of thinking I could specify what to run with "dub run..." additionally I don't want dub to rebuild all the time, so it boils down to:
dub install forever-d -local cd forever-d dub build cd .. dub build ./forever-d/forever-d foo <args>but this still has some drawbacks, since dub does not seem to add exec rights after building an executable?!
The current state, where everything is rebuilt every time is temporary and will be improved (see http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/352/). So the "dub run" approach will be fine and efficient at some point. A workaround for now is to use "dub run --rdmd", which does dependency tracking. But executable rights should always be present for the resulting binaries. If not, that's a bug of the used compiler.