January 13, 2018 Re: [howto] Serve ddox documentation on github.io deployed by Travis CI | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On Saturday, 13 January 2018 at 04:59:25 UTC, Martin Nowak wrote: > On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: >> [...] > > What do you mean with "taking care of it"? > It's a bit of a hen and egg problem, first you need a project before you can register it with code.dlang.org. So that seems like a sub-optimal place to help with project setup. > > [...] Citing Sönke: > The whole dub init -t feature is planned to be replaced by a more general approach, so it would be rather wasteful to invest more time than necessary in this. The new approach basically would simply look for a ":example" (or similar) sub package for the first dependency specified to dub init, uses that as the base for the newly created package, and would then just adjust the recipe according to the remaining init parameters. https://github.com/dlang/dub/pull/1326#issuecomment-357233196 |
January 13, 2018 Re: [howto] Serve ddox documentation on github.io deployed by Travis CI | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | On 2018-01-13 05:59, Martin Nowak wrote: > On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote: >>> Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering? >> >> This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete. > > What do you mean with "taking care of it"? Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well. -- /Jacob Carlborg |
January 13, 2018 Re: [howto] Serve ddox documentation on github.io deployed by Travis CI | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:
> On 2018-01-13 05:59, Martin Nowak wrote:
>> On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:
>>>> Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?
>>>
>>> This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
>>
>> What do you mean with "taking care of it"?
>
> Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.
Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.
|
January 18, 2018 Re: [howto] Serve ddox documentation on github.io deployed by Travis CI | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bastiaan Veelo | On Saturday, 13 January 2018 at 11:42:42 UTC, Bastiaan Veelo wrote:
> On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:
>> On 2018-01-13 05:59, Martin Nowak wrote:
>>> On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:
>>>>> Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?
>>>>
>>>> This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
>>>
>>> What do you mean with "taking care of it"?
>>
>> Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.
>
> Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.
I don't think it's good idea to centralize this.
First the existing tools are easy enough to use, though some articles are necessary to spread the knowledge.
Second it'd put more burden on very few people that are already maintaining an unproportionate part of the overall ecosystem.
Third ppl. might want to use different doc generators, styles, or host a project site.
Fourth you create new problems like CSRF when hostings docs on one domain, hence github pages have one subdomain per user.
We might want to add a configurable doc link to project settings on the registry, but the Readme is already a good or even better place.
|
February 01, 2018 Re: [howto] Serve ddox documentation on github.io deployed by Travis CI | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bastiaan Veelo | On Saturday, 13 January 2018 at 11:42:42 UTC, Bastiaan Veelo wrote:
> On Saturday, 13 January 2018 at 10:02:18 UTC, Jacob Carlborg wrote:
>> On 2018-01-13 05:59, Martin Nowak wrote:
>>> On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo wrote:
>>>>> Maybe worthwile to add this scaffolding to dub or some other tool? Anyone volunteering?
>>>>
>>>> This could be a good idea. Probably even better is to let code.dlang.org take care of it, which would make the whole token issue and setup obsolete.
>>>
>>> What do you mean with "taking care of it"?
>>
>> Perhaps to automatically generate documentation for all packages on code.dlang.org and publish it there as well.
>
> Yes that is what I meant, sorry for being vague. It’s been suggested before I think. It would be a lot more work than what you are suggesting and one does not have to exclude the other: a bot could clone the project repositories and generate documentation for each, without project owners needing to manage tokens.
I like this idea because:
1) it is more secure than allow to access Travis CI to my public repos
2) this can encourage writing documentation in those projects that not thinked about documentation
|
Copyright © 1999-2021 by the D Language Foundation