digitalmars.D.announce - code.dlang.org now supports categories and search
- =?ISO-8859-15?Q?S=F6nke_Ludwig?= (15/15) Oct 16 2013 The DUB package registry [1] has finally gained support for the text and...
- ponce (2/10) Oct 16 2013 Great! But I think the eloty categories must go until needed.
- ponce (2/3) Oct 16 2013 I meant "empty".
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (2/6) Oct 16 2013 https://github.com/rejectedsoftware/dub-registry/issues/21
- Andrej Mitrovic (6/13) Oct 16 2013 Not necessarily a bug, but when you search for "dlib", you only get
- =?ISO-8859-1?Q?S=F6nke_Ludwig?= (5/18) Oct 16 2013 I agree, that should probably count as one of the rough edges ;)
- =?ISO-8859-15?Q?S=F6nke_Ludwig?= (10/10) Oct 17 2013 There has been another important change that requires existing packages
- ilya-stromberg (11/23) Oct 17 2013 A little addition: allow use full license name, not only short
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (10/33) Oct 17 2013 How about letting the registry display the full name, but keep the short...
- ilya-stromberg (5/52) Oct 17 2013 We can use `+` to indicate "or later":
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (8/19) Oct 17 2013 Fair enough, that should work.
- ponce (1/7) Oct 17 2013 A lot of projects have per-file license specifics.
- ilya-stromberg (8/14) Oct 17 2013 It's impossible.
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (9/22) Oct 17 2013 If you have per-file differences, then this in fact means that both
- ilya-stromberg (4/14) Oct 17 2013 OK, understand your position. May be just provide special syntax
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (6/20) Oct 17 2013 It would have to be still valid JSON. So something like
- ilya-stromberg (8/38) Oct 17 2013 We can use "or" as default. So, your example:
- Jacob Carlborg (6/8) Oct 17 2013 Not necessarily. There can be two completely separated targets, that
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/10) Oct 17 2013 Not necessarily, but possibly, so it probably has to cope with it.
- Jacob Carlborg (4/7) Oct 17 2013 What's happens then with the main/super package, in regards to licensing...
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/10) Oct 17 2013 It's independent as long as it doesn't explicitly add the submodules as
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (2/15) Oct 17 2013 s/only reference a/just reference a single/
- ponce (5/12) Oct 17 2013 I have an example of such a thing, but honestly I don't think dub
- Andrej Mitrovic (10/12) Oct 17 2013 Speaking of which, if I forget to add the license to a package file is
- =?ISO-8859-1?Q?S=F6nke_Ludwig?= (6/18) Oct 17 2013 When you log in on the website and then go to "My packages", you'll see
- =?ISO-8859-1?Q?S=F6nke_Ludwig?= (6/10) Oct 17 2013 "dub publish" sounds like something that may considerably increase the
- Jacob Carlborg (7/12) Oct 17 2013 You could have something like this:
- =?ISO-8859-1?Q?S=F6nke_Ludwig?= (7/17) Oct 17 2013 Well, the other issue with that is that there is no guarantee that the
- Rory McGuire (5/30) Oct 17 2013 The only license JSON that looks valid is the string. Simple bracketing
- Jacob Carlborg (6/11) Oct 17 2013 Perhaps add the license: Apple Public Source License. This can be useful...
- ilya-stromberg (6/20) Oct 17 2013 Yes:
- =?ISO-8859-15?Q?S=F6nke_Ludwig?= (3/12) Oct 17 2013 Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public...
- Jacob Carlborg (4/6) Oct 17 2013 Cool, thanks.
- =?ISO-8859-15?Q?S=F6nke_Ludwig?= (3/18) Oct 17 2013 Now also with JavaScript support for switching categories and alphabetic...
- Tourist (3/35) Oct 17 2013 The website is a bit "jumpy" for me in Firefox upon navigation.
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/31) Oct 18 2013 I could barely reproduce it, but it looks like the cache headers that
- Tourist (3/46) Oct 18 2013 Yep, the issue is gone.
- Suliman (3/3) Oct 17 2013 code.dlang.org
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (10/12) Oct 17 2013 You mean like a flat list of tags?
- Andrej Mitrovic (4/6) Nov 09 2013 Is it possible to add a feature to sort the view by the added date of
- evilrat (4/9) Nov 09 2013 that would be really useful. who knows when something
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (3/10) Nov 10 2013 I've also thought about that in the past days, shouldn't be difficult to...
- Rory McGuire (3/17) Nov 10 2013 Would be nice if you could subscribe to a daily/weekly mail of the new
- Andrej Mitrovic (2/4) Nov 10 2013 I didn't want to appear needy, but yes an RSS feed would be awesome.
- Andrej Mitrovic (4/8) Nov 11 2013 Excellent, I see you've added the "Added" section now. However the
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
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
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
Am 16.10.2013 21:24, schrieb ponce:On Wednesday, 16 October 2013 at 19:23:54 UTC, ponce wrote:https://github.com/rejectedsoftware/dub-registry/issues/21Great! But I think the eloty categories must go until needed.I meant "empty".
Oct 16 2013
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
Am 16.10.2013 21:58, schrieb Andrej Mitrovic:On 10/16/13, Sönke Ludwig <sludwig outerproduct.org> wrote: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.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.
Oct 16 2013
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
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#licensesA 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
Am 17.10.2013 11:55, schrieb ilya-stromberg:On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote: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.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#licensesA 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.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
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote:Am 17.10.2013 11:55, schrieb ilya-stromberg:OK, maybe you are right.On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote: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.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#licensesA 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.We can use `+` to indicate "or later": "license": ["BSL-1.0+", "AFL-3.0+", "public domain"] I think it will be clear.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
Am 17.10.2013 12:14, schrieb ilya-stromberg: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.We can use `+` to indicate "or later": "license": ["BSL-1.0+", "AFL-3.0+", "public domain"] I think it will be clear.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
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
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
Am 17.10.2013 13:42, schrieb ilya-stromberg:On Thursday, 17 October 2013 at 10:39:45 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.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
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
Am 17.10.2013 14:13, schrieb ilya-stromberg:On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote: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.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
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:Am 17.10.2013 14:13, schrieb ilya-stromberg: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?On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote: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.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
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
Am 17.10.2013 15:26, schrieb Jacob Carlborg:On 2013-10-17 14:06, 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.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.
Oct 17 2013
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
Am 17.10.2013 16:59, schrieb Jacob Carlborg:On 2013-10-17 15:44, Sönke Ludwig wrote: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.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?
Oct 17 2013
Am 17.10.2013 17:02, schrieb Sönke Ludwig:Am 17.10.2013 16:59, schrieb Jacob Carlborg:s/only reference a/just reference a single/On 2013-10-17 15:44, Sönke Ludwig wrote: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.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?
Oct 17 2013
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg wrote:On 2013-10-17 14:06, Sönke Ludwig wrote: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.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.
Oct 17 2013
On 10/17/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:Having a single compact name reduces the chances for errorsSpeaking 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
Am 17.10.2013 14:25, schrieb Andrej Mitrovic:On 10/17/13, Sönke Ludwig <sludwig outerproduct.org> wrote: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.Having a single compact name reduces the chances for errorsSpeaking 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
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
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
Am 17.10.2013 15:28, schrieb Jacob Carlborg:On 2013-10-17 14:33, Sönke Ludwig wrote: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."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.
Oct 17 2013
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:tOn 2013-10-17 14:33, S=C3=B6nke Ludwig wrote: "dub publish" sounds like something that may considerably increase thecomplexity of the command line tool, especially in the long term, and i=toWell, 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 =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.get direct feedback. What about an e-mail notification, though? Seems like the most natural channel.
Oct 17 2013
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
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg wrote:On 2013-10-17 11:33, Sönke Ludwig wrote:Yes: Microsoft Public License (Ms-PL) Microsoft Reciprocal License (Ms-RL) http://en.wikipedia.org/wiki/Shared_sourceThere 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?
Oct 17 2013
Am 17.10.2013 15:31, schrieb Jacob Carlborg:On 2013-10-17 11:33, Sönke Ludwig wrote:Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public License).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?
Oct 17 2013
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
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
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 website is a bit "jumpy" for me in Firefox upon navigation. As if it loads without the CSS for a moment, and then restores.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
Am 17.10.2013 20:25, schrieb Tourist:On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote: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.Am 16.10.2013 21:01, schrieb Sönke Ludwig: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.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 18 2013
On Friday, 18 October 2013 at 10:23:20 UTC, Sönke Ludwig wrote:Am 17.10.2013 20:25, schrieb Tourist:Yep, the issue is gone. Good job!On Thursday, 17 October 2013 at 18:22:02 UTC, Sönke Ludwig wrote: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.Am 16.10.2013 21:01, schrieb Sönke Ludwig: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.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 18 2013
code.dlang.org Does we should have cats? maybe the organization by tags is better?
Oct 17 2013
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
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
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
Am 09.11.2013 18:18, schrieb evilrat:On Saturday, 9 November 2013 at 17:04:35 UTC, Andrej Mitrovic wrote:I've also thought about that in the past days, shouldn't be difficult to add (an RSS feed could also be interesting).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 10 2013
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:I've also thought about that in the past days, shouldn't be difficult to add (an RSS feed could also be interesting).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 10 2013
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
On 11/10/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:On 11/10/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote: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.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 11 2013