About API code comments and some behavior.

toras toras9000 at gmail.com
Sat Oct 29 07:28:36 UTC 2022


Hi

I then noticed that the enable_downloads/enable_statistics parameters in the create_repo API also had no effect.
It seems that no parameters are used and the repository's default settings are used. (I think this is probably the expected 
behavior.)
I think this one also needs to be removed from the API parameters and description.


Thanks

-- 
toras9000

On 2022/10/15 12:31, toras wrote:
> 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
> 



More information about the kallithea-general mailing list