• biocyberman (3/3) Dec 19 2016 I can write a short script to clone the remote git repo and use
• Jacob Carlborg (4/7) Dec 19 2016 It's not currently possible.
• biocyberman (6/13) Dec 19 2016 I see, it is both a good thing and a bad thing. Good thing is to
• Guillaume Piolat (7/12) Dec 19 2016 What you can do for private package as of today is:
• biocyberman (20/26) Dec 20 2016 Regarding path-based dependencies, how can I use a C or
• evilrat (5/26) Dec 20 2016 But you need one! If this simply source imports just make it dub
• Eugene Wissner (6/21) Dec 19 2016 To be honest there is no need for dub registry at all. Vim plugin

biocyberman <biocyberman gmail.com> writes:

I can write a short script to clone the remote git repo and use 
it as a submodule. But if it is possible to do with dub, it will 
be more convenient.

Jacob Carlborg <doob me.com> writes:

On 2016-12-19 13:11, biocyberman wrote:
 I can write a short script to clone the remote git repo and use it as a
 submodule. But if it is possible to do with dub, it will be more
 convenient.

It's not currently possible.

-- 
/Jacob Carlborg

biocyberman <biocyberman gmail.com> writes:

On Monday, 19 December 2016 at 14:18:17 UTC, Jacob Carlborg wrote:
 On 2016-12-19 13:11, biocyberman wrote:
 I can write a short script to clone the remote git repo and 
 use it as a
 submodule. But if it is possible to do with dub, it will be 
 more
 convenient.

 It's not currently possible.

I see, it is both a good thing and a bad thing. Good thing is to 
encourage developers to submit packages to central dub registry. 
Bad thing is, when that does not happen soon enough, other 
developers who use the package will have to do something for 
themselves.

Guillaume Piolat <first.last gmail.com> writes:

On Monday, 19 December 2016 at 14:45:07 UTC, biocyberman wrote:
 I see, it is both a good thing and a bad thing. Good thing is 
 to encourage developers to submit packages to central dub 
 registry. Bad thing is, when that does not happen soon enough, 
 other developers who use the package will have to do something 
 for themselves.

What you can do for private package as of today is:

- use path-based dependencies and put your packages in the same 
repo
- use git submodules and path-based dub dependencies together

If it's a public package, you can register yourself on the DUB 
repositery.

biocyberman <biocyberman gmail.com> writes:

On Monday, 19 December 2016 at 16:23:45 UTC, Guillaume Piolat 
wrote:

 What you can do for private package as of today is:

 - use path-based dependencies and put your packages in the same 
 repo
 - use git submodules and path-based dub dependencies together

 If it's a public package, you can register yourself on the DUB 
 repositery.

Regarding path-based dependencies, how can I use a C or 
non-dub-backing project as a dependency? I defined in dub.json 
like this:

"importPaths": ["non-dub-pkg"],
"dependencies": {
"non-dub-pkg": {"versions": "~master", "path": "./non-dub-pkg"}
}

And I got an error saying something like "dub could not find 
dub.json or pakage.json in 'non-dub-pkg' directory". That's true 
because it is a Makefile project.


 Eugene Wissner: I think a good official central registry is more 
reliable for production use. I don't know that js has ten 
registries. But if that is true, it is the lack of performance of 
the first official registry maintainer. Have one, do well, and 
recruit more talents. That will benefits people more than 
scattering resources to reinvent the wheel. Nonetheless, I agree 
that the support for ad-hoc dependencies is a good idea for 
development.

evilrat <evilrat666 gmail.com> writes:

On Tuesday, 20 December 2016 at 11:04:30 UTC, biocyberman wrote:
 On Monday, 19 December 2016 at 16:23:45 UTC, Guillaume Piolat 
 wrote:

 What you can do for private package as of today is:

 - use path-based dependencies and put your packages in the 
 same repo
 - use git submodules and path-based dub dependencies together

 If it's a public package, you can register yourself on the DUB 
 repositery.

 Regarding path-based dependencies, how can I use a C or 
 non-dub-backing project as a dependency? I defined in dub.json 
 like this:

 "importPaths": ["non-dub-pkg"],
 "dependencies": {
 "non-dub-pkg": {"versions": "~master", "path": "./non-dub-pkg"}
 }

 And I got an error saying something like "dub could not find 
 dub.json or pakage.json in 'non-dub-pkg' directory". That's 
 true because it is a Makefile project.

But you need one! If this simply source imports just make it dub 
package, if you need your sources and compiled library add 
pre-build command to dub package, see this
https://forum.dlang.org/post/giphqacvxoypzantqawh forum.dlang.org

Eugene Wissner <belka caraus.de> writes:

On Monday, 19 December 2016 at 14:45:07 UTC, biocyberman wrote:
 On Monday, 19 December 2016 at 14:18:17 UTC, Jacob Carlborg 
 wrote:
 On 2016-12-19 13:11, biocyberman wrote:
 I can write a short script to clone the remote git repo and 
 use it as a
 submodule. But if it is possible to do with dub, it will be 
 more
 convenient.

 It's not currently possible.

 I see, it is both a good thing and a bad thing. Good thing is 
 to encourage developers to submit packages to central dub 
 registry. Bad thing is, when that does not happen soon enough, 
 other developers who use the package will have to do something 
 for themselves.

To be honest there is no need for dub registry at all. Vim plugin 
managers can pull plugins from every github repository. 
Javascript ended up with 10 dependency managers every of which 
has its own registry (and npm as the most official of them). And 
the js case will happen to D aswell if it become more popular.