The DUB package registry [1] has finally gained support for the text and category based search of packages. There is also a category for D standard library candidate modules, as has been suggested recently.

If you already have any registered packages, please log in and add the proper categories to each of them ("My packages" -> click on package name). Should there be no exact category match, and that specific category is likely to have multiple entries in the future, please make a corresponding pull request against the category file [2] on GitHub.

It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4].

[1]: http://code.dlang.org
[2]: https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json
[3]: https://github.com/rejectedsoftware/dub-registry/issues
[4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

On Wednesday, 16 October 2013 at 19:01:45 UTC, Sönke Ludwig wrote:
> If you already have any registered packages, please log in and add the proper categories to each of them ("My packages" -> click on package name). Should there be no exact category match, and that specific category is likely to have multiple entries in the future, please make a corresponding pull request against the category file [2] on GitHub.
>
> It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4].

Great! But I think the eloty categories must go until needed.

On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
>
> Great! But I think the eloty categories must go until needed.

I meant "empty".

Am 16.10.2013 21:24, schrieb ponce:
> On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:
>>
>> Great! But I think the eloty categories must go until needed.
>
> I meant "empty".

https://github.com/rejectedsoftware/dub-registry/issues/21

On 10/16/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4].
>
> [1]: http://code.dlang.org
> [2]:
> https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json
> [3]: https://github.com/rejectedsoftware/dub-registry/issues
> [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

Not necessarily a bug, but when you search for "dlib", you only get one result, "dlib" (dlibgit is missing). I've tried using "dlib*" but that didn't work either. I think the search engine should try to be a little more lax and show partial matches too.

Am 16.10.2013 21:58, schrieb Andrej Mitrovic:
> On 10/16/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
>> It's still all a little rough around the edges. Any bugs can be reported
>> on the issue tracker [3] or discussed in the forum [4].
>>
>> [1]: http://code.dlang.org
>> [2]:
>> https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json
>> [3]: https://github.com/rejectedsoftware/dub-registry/issues
>> [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
>
> Not necessarily a bug, but when you search for "dlib", you only get
> one result, "dlib" (dlibgit is missing). I've tried using "dlib*" but
> that didn't work either. I think the search engine should try to be a
> little more lax and show partial matches too.
>

I agree, that should probably count as one of the rough edges ;)

Currently it uses a crude old way of doing text search for old versions of MongoDB, but in the latest versions they have much better means. I'll look into it.

There has been another important change that requires existing packages to be updated: All packages must now have the fields "description" and "license" present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available.

This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible.

[1]: http://code.dlang.org/package-format#licenses

On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
> There has been another important change that requires existing packages to be updated: All packages must now have the fields "description" and "license" present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available.
>
> This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible.
>
> [1]: http://code.dlang.org/package-format#licenses

A little addition: allow use full license name, not only short name:
`BSL-1.0` or `Boost Software License 1.0`
`AFL-3.0` or `Academic Free License 3.0`
It simplify creation of human-readable license name.

Add `public domain` license.

Add abbility to add the array with licenses:
"license": ["BSL-1.0", "AFL-3.0", "public domain"]
I think it's better than
"license": "BSL-1.0 or AFL-3.0 or public domain"

Am 17.10.2013 11:55, schrieb ilya-stromberg:
> On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
>> There has been another important change that requires existing
>> packages to be updated: All packages must now have the fields
>> "description" and "license" present to be published. The license field
>> has to be set according to the specification [1]. All existing
>> branches and version tags stay unaffected by this requirement and are
>> still available.
>>
>> This change has been done to prepare for an automated validation of
>> license terms in complex dependency hierarchies. This may be an
>> important feature as the number of available packages grows, which is
>> why this requirement has been introduced now as early as possible.
>>
>> [1]: http://code.dlang.org/package-format#licenses
>
> A little addition: allow use full license name, not only short name:
> `BSL-1.0` or `Boost Software License 1.0`
> `AFL-3.0` or `Academic Free License 3.0`
> It simplify creation of human-readable license name.

How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like "GPLv2" instead of "GPL-2.0", but in the end it just increases the potential for mistakes.

>
> Add `public domain` license.

Will do.

>
> Add abbility to add the array with licenses:
> "license": ["BSL-1.0", "AFL-3.0", "public domain"]
> I think it's better than
> "license": "BSL-1.0 or AFL-3.0 or public domain"

There will still be the need to specify "or later", so this will only make it partially more structured. I'm a little undecided on this one.

On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:
> Am 17.10.2013 11:55, schrieb ilya-stromberg:
>> On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote:
>>> There has been another important change that requires existing
>>> packages to be updated: All packages must now have the fields
>>> "description" and "license" present to be published. The license field
>>> has to be set according to the specification [1]. All existing
>>> branches and version tags stay unaffected by this requirement and are
>>> still available.
>>>
>>> This change has been done to prepare for an automated validation of
>>> license terms in complex dependency hierarchies. This may be an
>>> important feature as the number of available packages grows, which is
>>> why this requirement has been introduced now as early as possible.
>>>
>>> [1]: http://code.dlang.org/package-format#licenses
>>
>> A little addition: allow use full license name, not only short name:
>> `BSL-1.0` or `Boost Software License 1.0`
>> `AFL-3.0` or `Academic Free License 3.0`
>> It simplify creation of human-readable license name.
>
> How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like "GPLv2" instead of "GPL-2.0", but in the end it just increases the potential for mistakes.

OK, maybe you are right.

>
>>
>> Add `public domain` license.
>
> Will do.
>
>>
>> Add abbility to add the array with licenses:
>> "license": ["BSL-1.0", "AFL-3.0", "public domain"]
>> I think it's better than
>> "license": "BSL-1.0 or AFL-3.0 or public domain"
>
> There will still be the need to specify "or later", so this will only make it partially more structured. I'm a little undecided on this one.

We can use `+` to indicate "or later":
"license": ["BSL-1.0+", "AFL-3.0+", "public domain"]
I think it will be clear.