code.dlang.org now supports categories and search
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/
Re: code.dlang.org now supports categories and search
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.
Re: code.dlang.org now supports categories and search
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".
Re: code.dlang.org now supports categories and search
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
Re: code.dlang.org now supports categories and search
On 10/16/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search
Am 16.10.2013 21:58, schrieb Andrej Mitrovic: On 10/16/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search
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.
Re: code.dlang.org now supports categories and search
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.
Re: code.dlang.org now supports categories and search
code.dlang.org Does we should have cats? maybe the organization by tags is better?
Re: code.dlang.org now supports categories and search
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.
Re: code.dlang.org now supports categories and search
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.
Re: code.dlang.org now supports categories and search
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!
Re: code.dlang.org now supports categories and search
On 10/16/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search
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...
Re: code.dlang.org now supports categories and search
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).
Re: code.dlang.org now supports categories and search
Would be nice if you could subscribe to a daily/weekly mail of the new /updated packages . On 10 Nov 2013 10:25, "Sönke Ludwig" 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). >
Re: code.dlang.org now supports categories and search
On 11/10/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search
On 11/10/13, Andrej Mitrovic wrote: > On 11/10/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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"
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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"}]
Re: code.dlang.org now supports categories and search - license information now required
On 10/17/13, Sönke Ludwig 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).
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 14:25, schrieb Andrej Mitrovic: On 10/17/13, Sönke Ludwig 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.
Re: code.dlang.org now supports categories and search - license information now required
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?
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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 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
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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).
Re: code.dlang.org now supports categories and search - license information now required
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 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.
Re: code.dlang.org now supports categories and search - license information now required
The only license JSON that looks valid is the string. Simple bracketing will suffice for complex licenses. On 17 Oct 2013 16:05, "Sönke Ludwig" wrote: > 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 >> >> 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. >
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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
Re: code.dlang.org now supports categories and search - license information now required
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.
Re: code.dlang.org now supports categories and search - license information now required
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/
