Jump to page: 1 24  
Page
Thread overview
We need a community effort to maintain unmaintained dub packages, suggestions
May 22
mw
May 22
mw
May 22
Seb
May 22
mw
May 23
mw
May 23
mw
May 23
mw
May 23
mw
May 23
Dukc
May 23
mw
May 23
mw
May 23
welkam
May 23
mw
May 24
mw
May 24
Luis
May 24
mw
May 24
Luis
May 24
aberba
May 24
mw
May 23
Luis
May 23
mw
May 23
aberba
May 23
aberba
May 23
aberba
May 24
Basile B.
May 22
Hi,

I'm new here, try to start using D on my hobby projects, and I quickly run into issues when looking for supporting libraries.

I'm searching for a fixed point (decimal) type. On code.dlang.org, I found two packages having the functionalities that I need:

https://code.dlang.org/packages/decimal
https://code.dlang.org/packages/money

But I then run into issues with these packages (one has bug, and the other has compilation issues:
https://github.com/qznc/d-money/issues/11
https://github.com/rumbu13/decimal/issues/9)

And worse, it looks like both packages are no longer maintained by their original owners.

Then I found other people experienced the same difficulties, and started to re-invent those wheels, and the new packages are in 0.0.x stage with limited functionalities.

I think we are wasting our community effort here. I'm wondering:


1) can we form a dub packages maintenance group, to take care of these no longer maintained packages


2) can we change the code.dlang.org to allow other users take over those packages, e.g. after 2 weeks no reply from the original owner:

https://github.com/rumbu13/decimal/issues/9#issuecomment-632843049

'''
I would be willing to take over and fix the package.
I have forked it already months ago.
The most important think would be to give me access on code.dlang.org, so users would find it.
'''

https://github.com/rumbu13/decimal/issues/8 (this issue has been more than half year now).


3) make the new "may-take-over-when-needed" policy explicit on https://code.dlang.org/, when people register new packages.


4) create a "dub packages maintenance" group in this forum, so people can discuss these issues.


Anything else? thoughts?

May 22
On Friday, 22 May 2020 at 21:01:58 UTC, mw wrote:
> I think we are wasting our community effort here. I'm wondering:
>
>
> 1) can we form a dub packages maintenance group, to take care of these no longer maintained packages

I believe this is the purpose of the dlang-community github organization:

https://github.com/dlang-community
May 22
On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:
> I believe this is the purpose of the dlang-community github organization:
>
> https://github.com/dlang-community

Thanks for the link, can we add this link to https://code.dlang.org/

on each individual package's page, with the message:

If you found issues with this package, and it is no longer maintained and worth maintaining, please file an issue at:

https://github.com/dlang-community/discussions/issues


I'm adding the two packages I just found there.
May 22
On Friday, 22 May 2020 at 21:35:45 UTC, mw wrote:
> On Friday, 22 May 2020 at 21:15:42 UTC, Paul Backus wrote:
>> I believe this is the purpose of the dlang-community github organization:
>>
>> https://github.com/dlang-community
>
> Thanks for the link, can we add this link to https://code.dlang.org/
>
> on each individual package's page, with the message:
>
> If you found issues with this package, and it is no longer maintained and worth maintaining, please file an issue at:
>
> https://github.com/dlang-community/discussions/issues
>
>
> I'm adding the two packages I just found there.

Well the capacities that dlang-community can maintain are limited as well, so I'm not sure whether it's a good idea to advertise it so openly as a "free service", but I agree that it currently has too little presence (and maintainers). We generally only move a package if there's a volunteer in dlang community that actually is interested in maintaining the library (though it's not hard to become such a volunteer).
May 22
On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:
> , but I agree that it currently has too little presence (and maintainers). We generally only move a package if there's a volunteer in dlang community that actually is interested in maintaining the library (though it's not hard to become such a volunteer).

I can take one of the issue I found.  And @m3m0ry has express interest in take over the other one.

Just let me know the setup steps (any link somewhere?) on how to adopt the project to dlang-community, and someone who can do code review for me.

(I've noted on the issue ticket I filed.)

May 22
On Friday, 22 May 2020 at 23:33:44 UTC, mw wrote:
> On Friday, 22 May 2020 at 22:54:30 UTC, Seb wrote:
>> , but I agree that it currently has too little presence (and maintainers). We generally only move a package if there's a volunteer in dlang community that actually is interested in maintaining the library (though it's not hard to become such a volunteer).
>
> I can take one of the issue I found.  And @m3m0ry has express interest in take over the other one.
>
> Just let me know the setup steps (any link somewhere?) on how to adopt the project to dlang-community, and someone who can do code review for me.
>
> (I've noted on the issue ticket I filed.)

The best is if the original project author(s) transfer the project to the dlang-community repo. Then they remain maintainers of the repo, but also other members of the dlang-community organization can contribute or invite other potential maintainers.

In case they are unavailable, the next option would be to create a fork, transfer it yourself and register it as new package on dlang.org.
Later down the road, if original author responds, you can move the original repo and delete the fork.
May 23
I am happy for us to bring over a fixed-point data type, but not a money type.

Money requires external API access for get conversion rates ext.

A fixed point type at worst requires optimization for a given cpu.
Which is ok, very limited external dependencies needed to do that well.
May 23
On Saturday, 23 May 2020 at 00:31:48 UTC, rikki cattermole wrote:
> I am happy for us to bring over a fixed-point data type, but not a money type.
>
> Money requires external API access for get conversion rates ext.

That particular money package actually is very simple, it just implemented a fixed-point data type, and that's also what I need. (Ahh, even such a small thing is hard to find in dub, and this one is the most downloaded package in its kind with dub score 4.0).


The other decimal package actually looks pretty decent:

https://github.com/rumbu13/decimal/issues/7

but, right now it has compilation and test errors:
https://github.com/rumbu13/decimal/issues


(sigh ..., suppose I want to use D in my work, how I can convince my company to use it if I cannot even get my personal hobby project done in D?)

May 23
On Saturday, 23 May 2020 at 00:48:26 UTC, mw wrote:
>
> (sigh ..., suppose I want to use D in my work, how I can convince my company to use it if I cannot even get my personal hobby project done in D?)

Every language has unmaintained libraries. You could always fork and fix the errors.
May 23
On Saturday, 23 May 2020 at 01:31:38 UTC, Mike Parker wrote:
>
> Every language has unmaintained libraries. You could always fork and fix the errors.

Well, fork and fix is ok for personal project; but for the company, they will certainly say: why not choose a mature language with mature libraries? why not just use Java / Python / C++? why should we spend time fixing the libraries instead of getting our (functionality) work done?


I've some threads on this topic of industry use in the past:

April 24, 2012  How can D become adopted at my company?
https://forum.dlang.org/thread/exazrwacogokubvhjauh@forum.dlang.org

June 05, 2016   Andrei's list of barriers to D adoption
https://forum.dlang.org/post/nj2mm1$1hun$1@digitalmars.com


it's almost 8 years now, is D's industry adoption picking up?

« First   ‹ Prev
1 2 3 4