About API code comments and some behavior.
toras
toras9000 at gmail.com
Sat Oct 15 03:31:52 UTC 2022
Hi
> (If you are working from a repo checkout, it would be more helpful if you could send a diff.)
You are right. I wasn't used to it.
I will do so on future occasions.
>> + "gist": <gist_object>
> What is gist object? That should perhaps be clarified. Or perhaps it is a bug that it is returned ...
I wrote it in the sense that the <gist_object> in the result of this 'create_gist' is JSON with the same structure as the result
of 'get_gist'.
It's information about the created gist and I think it's the correct return value.
To avoid misinterpretation as an empty object, I imitated 'create_user' comment and wrote it like this.
Specifically, <gist_object> was such JSON data.
"gist": {"gist_id": 1, "type": "public", "access_id": "1", "description": "", "url": "http://localhost:9999/_admin/gists/1",
"expires": -1.0, "created_on": "2022-10-14T14:20:24.625"}
>> - The 'parent' parameter of 'update_repo_group' does not work.
> A quick look: The update_repo_group API arguments seems to be handled by
> https://kallithea-scm.org/repos/kallithea/files/7037365a/kallithea/model/repo_group.py#L278 . So perhaps the code in api.py
> should pass it as 'parent_group_id' instead of 'parent_group'?
> (But also, 'owner' doesn't seem to be handled at all. Does owner change really work for you? But also, I don't think it matters
> much who owns a repo group. Admin rights does the same thing. So repo group owner should perhaps just be removed from api.py and
> documentation?)
I'm not confident in my reading comprehension, but...
As you say, it looks like it would be necessary to pass it by 'parent_group_id'.
Also, is it necessary to not pass the 'parent_group_id' if it is not moved?
And I think that api.py should also resolve with get_repo_group_or_error() so that both name and id values are available.
And 'owner' certainly doesn't work either. I hadn't noticed.
Looking at the comments on RepoGroupModel.create(), did the implementer plan to use owner in the future?
There is also a countermeasure to make it changeable with update, right?
But for consistency in the current situation, it seems reasonable to remove it from the API parameters and documentation.
> Anyway:
> I also pushed some further cleanup of the documentation in api.py and api.rst .That's on the *stable* branch. It would be great
> if they could converge, and we could generate api.rst from api.py .
> If you want to improve documentation further, take a look at https://kallithea-scm.org/repos/kallithea/pull-request/325/_/api
> and propose api.py changes to make a grand unification.
Thank you. But as of now I do not have any further changes.
Thanks
--
toras9000
On 2022/10/14 21:51, Mads Kiilerich wrote:
> Hi
>
> Thank you. (If you are working from a repo checkout, it would be more helpful if you could send a diff.) I haven't verified in
> detail, but all the changes seem plausible ;-) I have pushed them to the stable branch.
>
> One question though:
>
>> id : <id_given_in_input>
>> result : {
>> "msg": "created new gist",
>> - "gist": {}
>> + "gist": <gist_object>
>> }
>> error : null
>
> What is gist object? That should perhaps be clarified. Or perhaps it is a bug that it is returned ...
>
>> - The 'parent' parameter of 'update_repo_group' does not work.
>> It appears to accept the 'parent' parameter, but specifying it seems to have no effect.
>
> A quick look: The update_repo_group API arguments seems to be handled by
> https://kallithea-scm.org/repos/kallithea/files/7037365a/kallithea/model/repo_group.py#L278 . So perhaps the code in api.py
> should pass it as 'parent_group_id' instead of 'parent_group'?
> (But also, 'owner' doesn't seem to be handled at all. Does owner change really work for you? But also, I don't think it matters
> much who owns a repo group. Admin rights does the same thing. So repo group owner should perhaps just be removed from api.py and
> documentation?)
>
> Anyway:
> I also pushed some further cleanup of the documentation in api.py and api.rst .That's on the *stable* branch. It would be great
> if they could converge, and we could generate api.rst from api.py .
> If you want to improve documentation further, take a look at https://kallithea-scm.org/repos/kallithea/pull-request/325/_/api
> and propose api.py changes to make a grand unification.
>
> /Mads
>
>
> On 13/10/2022 15:00, toras wrote:
>> Hi.
>>
>>
>> There was an API-related topic a little while ago,so there may be things that are currently being changed, but I recently
>> noticed something while writing a client that uses the API, so I'd like to report it.
>>
>> - The comments in api.py have some differences from the implementation.
>> I tried calling the API and attached a file that changed the part that is different from the result.
>> (Based on commit 7037365a7bc3.)
>> I don't know if this is necessary, but for your information.
>>
>> - The 'parent' parameter of 'update_repo_group' does not work.
>> It appears to accept the 'parent' parameter, but specifying it seems to have no effect.
>>
>>
>> Thanks
>>
>> --
>> toras9000
>>
>>
>> _______________________________________________
>> kallithea-general mailing list
>> kallithea-general at sfconservancy.org
>> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
More information about the kallithea-general
mailing list