Jump to page: 1 2 3
Thread overview
Is it possible for the deimos repositories to be added to the dub registry please?
Jan 05, 2014
Gary Willoughby
Jan 05, 2014
Kelet
Jan 05, 2014
Kelet
Jan 06, 2014
Jacob Carlborg
Jan 06, 2014
Gary Willoughby
Jan 06, 2014
Jacob Carlborg
Jan 06, 2014
David Nadlinger
Jan 06, 2014
ilya-stromberg
Jan 06, 2014
David Nadlinger
Jan 06, 2014
Jacob Carlborg
Jan 06, 2014
David Nadlinger
Jan 07, 2014
Jacob Carlborg
Jan 07, 2014
Gary Willoughby
Jan 07, 2014
Gary Willoughby
Jan 07, 2014
Dicebot
Jan 06, 2014
ilya-stromberg
Jan 07, 2014
Mike Parker
Jan 07, 2014
ponce
Jan 07, 2014
Andrej Mitrovic
Jan 06, 2014
Dicebot
Jan 26, 2014
Andrej Mitrovic
Jan 26, 2014
Andrej Mitrovic
Jan 26, 2014
John Colvin
January 05, 2014
Is it possible for the deimos[1] repositories to be added to the dub registry[2] please?

I'm working on a project that uses the deimos x11 bindings and it would be nice to handle building the project using dub. Also, i won't have to distribute the x11 bindings with my project.

[1]: https://github.com/D-Programming-Deimos
[2]: http://code.dlang.org/
January 05, 2014
On Sunday, 5 January 2014 at 20:48:00 UTC, Gary Willoughby wrote:
> Is it possible for the deimos[1] repositories to be added to the dub registry[2] please?
>
> I'm working on a project that uses the deimos x11 bindings and it would be nice to handle building the project using dub. Also, i won't have to distribute the x11 bindings with my project.
>
> [1]: https://github.com/D-Programming-Deimos
> [2]: http://code.dlang.org/

Yes,

A lot of Deimos repositories are already in the DUB registry. I think they are handled individually and not collectively. I would imagine forking the repository, creating a DUB package configuration, and submitting a pull request would be the best course of action here. If the pull request is not accepted in a reasonable and timely manner I don't think anyone would object to you adding the forked repository to the DUB registry.

Regards,
Kelet
January 05, 2014
It is also worth noting that specifying git repository URLs rather than being locked into the registry should be added to DUB eventually[1]. Until then, you can always fork it, add a DUB package configuration, and install the package locally or use the "complex variant"[2] of DUB version specifications to use a local path.

[1]: https://github.com/rejectedsoftware/dub/issues/104
[2]: http://code.dlang.org/package-format Search for "complex variant"

Regards,
Kelet
January 06, 2014
On 2014-01-05 21:57, Kelet wrote:

> A lot of Deimos repositories are already in the DUB registry.

I think we should close down Deimos now that we have Dub.

-- 
/Jacob Carlborg
January 06, 2014
On Monday, 6 January 2014 at 09:52:53 UTC, Jacob Carlborg wrote:
> On 2014-01-05 21:57, Kelet wrote:
>
>> A lot of Deimos repositories are already in the DUB registry.
>
> I think we should close down Deimos now that we have Dub.

Who currently controls deimos?
January 06, 2014
On 2014-01-06 11:29, Gary Willoughby wrote:

> Who currently controls deimos?

The D core team.

-- 
/Jacob Carlborg
January 06, 2014
On Monday, 6 January 2014 at 09:52:53 UTC, Jacob Carlborg wrote:
> On 2014-01-05 21:57, Kelet wrote:
>
>> A lot of Deimos repositories are already in the DUB registry.
>
> I think we should close down Deimos now that we have Dub.

I don't think so. Having a curated set of bindings that follow a common quality standard is something I'd regard as desirable.

The first thing I would think about modifying with Dub gaining adoption is actually the Phobos inclusion process…

David
January 06, 2014
On Monday, 6 January 2014 at 16:27:14 UTC, David Nadlinger wrote:
> On Monday, 6 January 2014 at 09:52:53 UTC, Jacob Carlborg wrote:
>> On 2014-01-05 21:57, Kelet wrote:
>>
>>> A lot of Deimos repositories are already in the DUB registry.
>>
>> I think we should close down Deimos now that we have Dub.
>
> I don't think so. Having a curated set of bindings that follow a common quality standard is something I'd regard as desirable.

Unfortunately, Deimos does not good enough.
I used `libfcgi` ~2 years ago, and it was completely broken (segmentation fault after 1-st GC memory free).
So, I agree with Jacob: we should close down Deimos. As alternative, we should use the same review process as for Phobos.
January 06, 2014
On Monday, 6 January 2014 at 16:27:14 UTC, David Nadlinger wrote:
> On Monday, 6 January 2014 at 09:52:53 UTC, Jacob Carlborg wrote:
>> On 2014-01-05 21:57, Kelet wrote:
>>
>>> A lot of Deimos repositories are already in the DUB registry.
>>
>> I think we should close down Deimos now that we have Dub.
>
> I don't think so. Having a curated set of bindings that follow a common quality standard is something I'd regard as desirable.

As have been already mentioned, problem is there is no actual quality standard guaranteed by Phobos, just a maintenance delay because repo is out of control of author. Deimos has very floating nature contrary to Phobos and we don't have workforce to re-review packages there all the time.
January 06, 2014
On Monday, 6 January 2014 at 16:49:44 UTC, ilya-stromberg wrote:
> Unfortunately, Deimos does not good enough.
> I used `libfcgi` ~2 years ago, and it was completely broken (segmentation fault after 1-st GC memory free).
> So, I agree with Jacob: we should close down Deimos. As alternative, we should use the same review process as for Phobos.

So there is a single library that is not "good enough". Where is your bug report? Your pull request?

I just had a look at the libfcgi repository, and it seems like Jonathan recommends building the binding with "ldc2 -shared" in the readme. There are two things wrong with this:
  1) -shared is not yet supported in LDC for D2 (it will lead to GC-related crashes), and Jonathan knows this.
  2) Deimos headers should *never* require actually building something, they should be "header-only", in C terms.
So, yes, there are apparently problems with getting the Deimos idea across (and Walter's code review practices), but I don't see how this justifies ditching the whole idea.

The idea behind Deimos is that there should be a single of plain, "no-frills" C bindings, because it makes exactly zero sense to duplicate work here. Other people can build on these for higher-level libraries. Whether these are managed in one central place or in separate repositories doesn't matter in the end; the thing that counts is that we have a common understanding of how bindings that are "officially" accepted are supposed look like. If every single C binding on code.dlang.org follows a different naming scheme, loading convention, …, just using a C library will become a lot less of a plug-and-play experience than it could be.

Yes, there are currently issues with the way Deimos is handled, starting with the fact that a ridiculously small number of people actually has push access to them (e.g. I have access to all the D-P-L ones, but not to Deimos). In fact, I think it might even make sense idea to give the original creator of a binding write access to the repository after the initial review is complete, which ensures that the author is familiar with the Deimos conventions. There isn't really a lot to get wrong with C bindings that would necessitate much review afterwards.

Also, we need to improve the documentation about the Deimos standards and process. But still, I don't think we should outright ditch the idea at this point; the situation certainly won't get better without Deimos being in the picture.

David
« First   ‹ Prev
1 2 3