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.

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

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.

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.

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.

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.

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