www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - code.dlang.org now supports categories and search

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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/
Oct 16 2013
next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
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.
Oct 16 2013
parent reply "ponce" <contact gam3sfrommars.fr> writes:
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".
Oct 16 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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
Oct 16 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/13, S=F6nke 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.j=
son
 [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.
Oct 16 2013
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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.
Oct 16 2013
prev sibling next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
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
Oct 17 2013
next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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"
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
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.
Oct 17 2013
next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
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.
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 12:14, schrieb ilya-stromberg:
 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.
Fair enough, that should work. But one potential issue just occurred to me. What if a product is licensed under multiple licenses that must _all_ apply? That would basically be "MPL-2.0 and Apache-1.0" instead of "or". This is something that happens quite frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright.
Oct 17 2013
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
 But one potential issue just occurred to me. What if a product 
 is licensed under multiple licenses that must _all_ apply? That 
 would basically be "MPL-2.0 and Apache-1.0" instead of "or". 
 This is something that happens quite frequently when code is 
 taken from multiple projects or when the license was changed, 
 but some files were under foreign copyright.
A lot of projects have per-file license specifics.
Oct 17 2013
prev sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Thursday, 17 October 2013 at 10:39:45 UTC, S├Ânke Ludwig wrote:
 But one potential issue just occurred to me. What if a product 
 is licensed under multiple licenses that must _all_ apply? That 
 would basically be "MPL-2.0 and Apache-1.0" instead of "or". 
 This is something that happens quite frequently when code is 
 taken from multiple projects or when the license was changed, 
 but some files were under foreign copyright.
It's impossible. For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires both GPL-2.0 AND GPL-3.0, it means that we have invalid license items. So, we should provide only "OR" modifier, not "AND". And I agree with ponce: we should provide a per-file license specifics, it should solve your problem.
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 13:42, schrieb ilya-stromberg:
 On Thursday, 17 October 2013 at 10:39:45 UTC, S├Ânke Ludwig wrote:
 But one potential issue just occurred to me. What if a product is
 licensed under multiple licenses that must _all_ apply? That would
 basically be "MPL-2.0 and Apache-1.0" instead of "or". This is
 something that happens quite frequently when code is taken from
 multiple projects or when the license was changed, but some files were
 under foreign copyright.
It's impossible. For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires both GPL-2.0 AND GPL-3.0, it means that we have invalid license items. So, we should provide only "OR" modifier, not "AND". And I agree with ponce: we should provide a per-file license specifics, it should solve your problem.
If you have per-file differences, then this in fact means that both licenses need to be obeyed when using the package. If those licenses are incompatible, that's a problem of the package combining them - it's basically unusable then. But going a per-file way is by-far too detailed. It's hard enough to assure proper per-package licensing and keeping license comments up to date, but this will IMO just result in chaos. Also, while GPL 2 and 3 may not be compatible, there are other licenses which are compatible, but one is not a superset of the other.
Oct 17 2013
next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Thursday, 17 October 2013 at 12:06:49 UTC, S├Ânke Ludwig wrote:
 If you have per-file differences, then this in fact means that 
 both licenses need to be obeyed when using the package. If 
 those licenses are incompatible, that's a problem of the 
 package combining them - it's basically unusable then. But 
 going a per-file way is by-far too detailed. It's hard enough 
 to assure proper per-package licensing and keeping license 
 comments up to date, but this will IMO just result in chaos.

 Also, while GPL 2 and 3 may not be compatible, there are other 
 licenses which are compatible, but one is not a superset of the 
 other.
OK, understand your position. May be just provide special syntax for this cases, for example: "license": [{"BSL-1.0", "MIT"}]
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
 On Thursday, 17 October 2013 at 12:06:49 UTC, S├Ânke Ludwig wrote:
 If you have per-file differences, then this in fact means that both
 licenses need to be obeyed when using the package. If those licenses
 are incompatible, that's a problem of the package combining them -
 it's basically unusable then. But going a per-file way is by-far too
 detailed. It's hard enough to assure proper per-package licensing and
 keeping license comments up to date, but this will IMO just result in
 chaos.

 Also, while GPL 2 and 3 may not be compatible, there are other
 licenses which are compatible, but one is not a superset of the other.
OK, understand your position. May be just provide special syntax for this cases, for example: "license": [{"BSL-1.0", "MIT"}]
It would have to be still valid JSON. So something like "license": {"or": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"]} would work. But that is hardly more practical than "license": "BSL-1.0 and MIT or GPL-2.0" With the advantage of not requiring operator precedence, though.
Oct 17 2013
parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Thursday, 17 October 2013 at 12:27:02 UTC, S├Ânke Ludwig wrote:
 Am 17.10.2013 14:13, schrieb ilya-stromberg:
 On Thursday, 17 October 2013 at 12:06:49 UTC, S├Ânke Ludwig 
 wrote:
 If you have per-file differences, then this in fact means 
 that both
 licenses need to be obeyed when using the package. If those 
 licenses
 are incompatible, that's a problem of the package combining 
 them -
 it's basically unusable then. But going a per-file way is 
 by-far too
 detailed. It's hard enough to assure proper per-package 
 licensing and
 keeping license comments up to date, but this will IMO just 
 result in
 chaos.

 Also, while GPL 2 and 3 may not be compatible, there are other
 licenses which are compatible, but one is not a superset of 
 the other.
OK, understand your position. May be just provide special syntax for this cases, for example: "license": [{"BSL-1.0", "MIT"}]
It would have to be still valid JSON. So something like "license": {"or": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"]} would work. But that is hardly more practical than "license": "BSL-1.0 and MIT or GPL-2.0" With the advantage of not requiring operator precedence, though.
We can use "or" as default. So, your example: "license": [{"and": ["BSL-1.0", "MIT]}, "GPL-2.0"] Yes, the example "license": "BSL-1.0 and MIT or GPL-2.0" looks better, but what about more complex cases: "license": "BSL-1.0 and MIT or GPL-2.0 and BSL-1.0" What does it mean?
Oct 17 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 14:06, S├Ânke Ludwig wrote:

 If you have per-file differences, then this in fact means that both
 licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that don't share any code. I don't know if that's possible in Dub, but in theory it would be. -- /Jacob Carlborg
Oct 17 2013
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 15:26, schrieb Jacob Carlborg:
 On 2013-10-17 14:06, S├Ânke Ludwig wrote:

 If you have per-file differences, then this in fact means that both
 licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that don't share any code. I don't know if that's possible in Dub, but in theory it would be.
Not necessarily, but possibly, so it probably has to cope with it. One possibility to handle your example would be to make different sub packages for the two targets.
Oct 17 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 15:44, S├Ânke Ludwig wrote:

 Not necessarily, but possibly, so it probably has to cope with it.

 One possibility to handle your example would be to make different sub
 packages for the two targets.
What's happens then with the main/super package, in regards to licensing? -- /Jacob Carlborg
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 16:59, schrieb Jacob Carlborg:
 On 2013-10-17 15:44, S├Ânke Ludwig wrote:

 Not necessarily, but possibly, so it probably has to cope with it.

 One possibility to handle your example would be to make different sub
 packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want.
Oct 17 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 17:02, schrieb S├Ânke Ludwig:
 Am 17.10.2013 16:59, schrieb Jacob Carlborg:
 On 2013-10-17 15:44, S├Ânke Ludwig wrote:

 Not necessarily, but possibly, so it probably has to cope with it.

 One possibility to handle your example would be to make different sub
 packages for the two targets.
What's happens then with the main/super package, in regards to licensing?
It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want.
s/only reference a/just reference a single/
Oct 17 2013
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg 
wrote:
 On 2013-10-17 14:06, S├Ânke Ludwig wrote:

 If you have per-file differences, then this in fact means that 
 both
 licenses need to be obeyed when using the package.
Not necessarily. There can be two completely separated targets, that don't share any code. I don't know if that's possible in Dub, but in theory it would be.
I have an example of such a thing, but honestly I don't think dub should go that much far. Just providing the superset of what licenses a package _might_ fall under is already useful.
Oct 17 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/17/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 Having a single compact name reduces the
 chances for errors
Speaking of which, if I forget to add the license to a package file is there any way to get this information from the server? I mean like a page saying that my package was rejected because it's missing X or Y, rather than having to guess whether the package file is bad or the server is just temporarily overloaded. Personally I think it would be better if we had a "dub publish" command, which would then error back if the server rejects the package, rather than make this whole process automated based on searching github (I assume this is how the dub server works now).
Oct 17 2013
next sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
 On 10/17/13, S÷nke Ludwig <sludwig outerproduct.org> wrote:
 Having a single compact name reduces the
 chances for errors
Speaking of which, if I forget to add the license to a package file is there any way to get this information from the server? I mean like a page saying that my package was rejected because it's missing X or Y, rather than having to guess whether the package file is bad or the server is just temporarily overloaded. Personally I think it would be better if we had a "dub publish" command, which would then error back if the server rejects the package, rather than make this whole process automated based on searching github (I assume this is how the dub server works now).
When you log in on the website and then go to "My packages", you'll see a table of all packages along with excerpts of possible errors. You can then click on each package to see the full list of errors. There is also a button to trigger a manual update after changes now, so that the usual uncertain wait is not necessary anymore.
Oct 17 2013
prev sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:
 Personally I think it would be better if we had a "dub publish"
 command, which would then error back if the server rejects the
 package, rather than make this whole process automated based on
 searching github (I assume this is how the dub server works now).
"dub publish" sounds like something that may considerably increase the complexity of the command line tool, especially in the long term, and it also increases the coupling to the public registry, whereas now it just needs a very small HTTP API that can be fulfilled by any HTTP file server. So I'd rather want to avoid that if possible.
Oct 17 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 14:33, S÷nke Ludwig wrote:

 "dub publish" sounds like something that may considerably increase the
 complexity of the command line tool, especially in the long term, and it
 also increases the coupling to the public registry, whereas now it just
 needs a very small HTTP API that can be fulfilled by any HTTP file
 server. So I'd rather want to avoid that if possible.
You could have something like this: dub publish <git-tag> Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically. -- /Jacob Carlborg
Oct 17 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 17.10.2013 15:28, schrieb Jacob Carlborg:
 On 2013-10-17 14:33, S÷nke Ludwig wrote:

 "dub publish" sounds like something that may considerably increase the
 complexity of the command line tool, especially in the long term, and it
 also increases the coupling to the public registry, whereas now it just
 needs a very small HTTP API that can be fulfilled by any HTTP file
 server. So I'd rather want to avoid that if possible.
You could have something like this: dub publish <git-tag> Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically.
Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible to get direct feedback. What about an e-mail notification, though? Seems like the most natural channel.
Oct 17 2013
parent Rory McGuire <rjmcguire gmail.com> writes:
The only license JSON that looks valid is the string. Simple bracketing
will suffice for complex licenses.
On 17 Oct 2013 16:05, "S=C3=B6nke Ludwig" <sludwig outerproduct.org> wrote:

 Am 17.10.2013 15:28, schrieb Jacob Carlborg:

 On 2013-10-17 14:33, S=C3=B6nke Ludwig wrote:

  "dub publish" sounds like something that may considerably increase the
 complexity of the command line tool, especially in the long term, and i=
t
 also increases the coupling to the public registry, whereas now it just
 needs a very small HTTP API that can be fulfilled by any HTTP file
 server. So I'd rather want to avoid that if possible.
You could have something like this: dub publish <git-tag> Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically.
Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible =
to
 get direct feedback.

 What about an e-mail notification, though? Seems like the most natural
 channel.
Oct 17 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 11:33, 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.
Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft? -- /Jacob Carlborg
Oct 17 2013
next sibling parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg 
wrote:
 On 2013-10-17 11:33, 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.
Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft?
Yes: Microsoft Public License (Ms-PL) Microsoft Reciprocal License (Ms-RL) http://en.wikipedia.org/wiki/Shared_source
Oct 17 2013
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 17.10.2013 15:31, schrieb Jacob Carlborg:
 On 2013-10-17 11:33, 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.
Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft?
Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public License).
Oct 17 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-17 15:53, S÷nke Ludwig wrote:

 Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public
 License).
Cool, thanks. -- /Jacob Carlborg
Oct 17 2013
prev sibling next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 16.10.2013 21:01, schrieb S÷nke Ludwig:
 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/
Now also with JavaScript support for switching categories and alphabetic sorting.
Oct 17 2013
parent reply "Tourist" <gravatar gravatar.com> writes:
On Thursday, 17 October 2013 at 18:22:02 UTC, S├Ânke Ludwig wrote:
 Am 16.10.2013 21:01, schrieb S├Ânke Ludwig:
 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/
Now also with JavaScript support for switching categories and alphabetic sorting.
The website is a bit "jumpy" for me in Firefox upon navigation. As if it loads without the CSS for a moment, and then restores.
Oct 17 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 17.10.2013 20:25, schrieb Tourist:
 On Thursday, 17 October 2013 at 18:22:02 UTC, S├Ânke Ludwig wrote:
 Am 16.10.2013 21:01, schrieb S├Ânke Ludwig:
 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/
Now also with JavaScript support for switching categories and alphabetic sorting.
The website is a bit "jumpy" for me in Firefox upon navigation. As if it loads without the CSS for a moment, and then restores.
I could barely reproduce it, but it looks like the cache headers that the server sent caused the CSS to be re-requested for every page load. Should be fixed now.
Oct 18 2013
parent "Tourist" <gravatar gravatar.com> writes:
On Friday, 18 October 2013 at 10:23:20 UTC, S├Ânke Ludwig wrote:
 Am 17.10.2013 20:25, schrieb Tourist:
 On Thursday, 17 October 2013 at 18:22:02 UTC, S├Ânke Ludwig 
 wrote:
 Am 16.10.2013 21:01, schrieb S├Ânke Ludwig:
 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/
Now also with JavaScript support for switching categories and alphabetic sorting.
The website is a bit "jumpy" for me in Firefox upon navigation. As if it loads without the CSS for a moment, and then restores.
I could barely reproduce it, but it looks like the cache headers that the server sent caused the CSS to be re-requested for every page load. Should be fixed now.
Yep, the issue is gone. Good job!
Oct 18 2013
prev sibling next sibling parent reply "Suliman" <evermind live.ru> writes:
code.dlang.org

Does we should have cats? maybe the organization by tags is 
better?
Oct 17 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 18.10.2013 08:47, schrieb Suliman:
 code.dlang.org

 Does we should have cats? maybe the organization by tags is better?
You mean like a flat list of tags? Currently it's something like hierarchical tags. Each package can have multiple categories, and the specific categories, as well as the ancestor categories will all match. But one thing that I'd like to improve is the UI for category selection and make it hierarchical and step by step (like the path navigation of e.g. modern Windows Explorer). Also maybe the hierarchy itself could be improved (it's in a very ad-hoc state), so that there is less redundancy and selecting multiple tags/categories is used to disambiguate instead.
Oct 17 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 The DUB package registry [1] has finally gained support for the text and
 category based search of packages.
Is it possible to add a feature to sort the view by the added date of a package (rather than just updated/name sorting)? Sometimes I'd like to see which packages are new in the registry.
Nov 09 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic 
wrote:
 Is it possible to add a feature to sort the view by the added 
 date of
 a package (rather than just updated/name sorting)? Sometimes 
 I'd like
 to see which packages are new in the registry.
that would be really useful. who knows when something interresting added to dub, this would allow to see...
Nov 09 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 09.11.2013 18:18, schrieb evilrat:
 On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:
 Is it possible to add a feature to sort the view by the added date of
 a package (rather than just updated/name sorting)? Sometimes I'd like
 to see which packages are new in the registry.
that would be really useful. who knows when something interresting added to dub, this would allow to see...
I've also thought about that in the past days, shouldn't be difficult to add (an RSS feed could also be interesting).
Nov 10 2013
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
Would be nice if you could subscribe to a daily/weekly mail of the new
/updated packages .
On 10 Nov 2013 10:25, "S=C3=B6nke Ludwig" <sludwig outerproduct.org> wrote:

 Am 09.11.2013 18:18, schrieb evilrat:

 On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:

 Is it possible to add a feature to sort the view by the added date of
 a package (rather than just updated/name sorting)? Sometimes I'd like
 to see which packages are new in the registry.
that would be really useful. who knows when something interresting added to dub, this would allow to see...
I've also thought about that in the past days, shouldn't be difficult to add (an RSS feed could also be interesting).
Nov 10 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/10/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 I've also thought about that in the past days, shouldn't be difficult to
 add (an RSS feed could also be interesting).
I didn't want to appear needy, but yes an RSS feed would be awesome.
Nov 10 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/10/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 On 11/10/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:
 I've also thought about that in the past days, shouldn't be difficult to
 add (an RSS feed could also be interesting).
I didn't want to appear needy, but yes an RSS feed would be awesome.
Excellent, I see you've added the "Added" section now. However the Date column should likely reference the date added rather than the date updated when "Added" is selected.
Nov 11 2013