Move src/ to src/yunohost

[Salamandar]

Reasons to do that :

• This is the python way.
  See https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/ : It's either ./projectname or ./src/projectname.
• The current layout breaks the way tools search for packages:
  • Pytest doesn't work out of the box, we need to make a symlink to make CI work:
    

    yunohost/.gitlab/ci/test.gitlab-ci.yml

    Line 16 in ceae72b

    - ln -s src yunohost

    
    What that means is that pytest does not work on a developer's working copy out of the box.
  • ty doesn't work properly, a not-completely functional workaround was found but that's not enough:
    

    yunohost/pyproject.toml

    Line 82 in ceae72b

    environment.root = ["."]

  • coverage isn't able either to detect the root of the package, we need to specify it:
    

    yunohost/pyproject.toml

    Line 109 in ceae72b

    source = ["src/"]

  • And there are other tools I've used to work on yunohost that aren't happy with the current layout, but i don't have them on top of my head right now.

[alexAubin]

No god please no

[Salamandar]

No god please no

But what are the arguments ? It's so annoying having tools not understanding the repo topology.

[Josue-T]

I think the issue is that this PR create a lot of conflict with others PR and we have a high number of that. I think we firstly need close as much as possible all PR before doing the refactoring like this to avoid as much as possible conflict to solve this merge. And I think it's the same question for #2262.

Note I discussed with @zamentur about #2262 and this was the conclusion.

But maybe @alexAubin was thinking about some other reason.

[Salamandar]

This PR is targetting Trixie, so not many conflicts. Also git knows how to handle renames, rebasing other PRs will be at zero cost.

[zamentur]

Hi @Salamandar ,

Could you detail your PR: what was your initial problem ? how this topology affects your tooling ? Which tooling ? I don't understand why this PR could avoid us to use symlink in ynh-dev ?

We also need to know which part of this has been tested or not and how.

And if you can detail a bit more the gain to merge this PR to see if it's really needed to make this kind of change now.

This PR is targeting Trixie, so not many conflicts.

This means having one method for bookworm and another for trixie (ynh-dev to adapt, maybe ci, etc.), so dev have to update at least ynh-dev (and the tool need to be adapted before...)

Also git knows how to handle renames, rebasing other PRs will be at zero cost.

Yes and no. For example, if a new file is created in a PR into src, it won't be magically renamed to src/yunohost.
If one of this file is deleted before this rename in another PR, it will generate a conflict.

So i am pretty sure it won't be zero cost...

[zamentur]

If you ask yourself why i write in bold about pr description: it's because it's not the first PR where i ask for details...

https://github.com/YunoHost/yunohost/pulls?q=is%3Apr%20is%3Aopen%20label%3A%22pr%20description%20needed%22

The PR template can help you, even if some parts are verbose and could probably ignored sometimes... However, we really need to know the details of the problem AND how it has been tested.

[Salamandar]

Hi @Salamandar ,

Could you detail your PR: what was your initial problem ? how this topology affects your tooling ? Which tooling ? I don't understand why this PR could avoid us to use symlink in ynh-dev ?

See the updated PR comment.

We also need to know which part of this has been tested or not and how.

As core CI was broken for the last ~ 10 days, I couldn't test much.

And if you can detail a bit more the gain to merge this PR to see if it's really needed to make this kind of change now.

See the updated PR comment.

This means having one method for bookworm and another for trixie (ynh-dev to adapt, maybe ci, etc.), so dev have to update at least ynh-dev (and the tool need to be adapted before...)

Yeah, that's not a blocker, right ?

Yes and no. For example, if a new file is created in a PR into src, it won't be magically renamed to src/yunohost. If one of this file is deleted before this rename in another PR, it will generate a conflict.

Yeah, okay, that won't be absolutely zero cost. But that's not what I call a blocker. We have 60 PRs, there's certainly not many PRs with new files in src/.

[Salamandar]

If you ask yourself why i write in bold about pr description: it's because it's not the first PR where i ask for details...

YunoHost/yunohost/pulls (is:open label:"pr description needed")

From these PRs, only one (appart from this one) was not as draft. And I moved it as draft. So… It makes sense not having a complete description when the PR is not ready.

[zamentur]

So… It makes sense not having a complete description when the PR is not ready.

At the beginning yes, but after month i could be useful to have a related issue or a description IMHO.

But you are right, as i don't review drafts anymore, it's not so annoying, even if the label with the growing number of PR in github UX is anxiety-inducing.

[zamentur]

Yeah, okay, that won't be absolutely zero cost. But that's not what I call a blocker. We have 60 PRs, there's certainly not many PRs with new files in src/.

I guess we could discuss it on next meeting, PRlanta or during yunocamp.

[Josue-T]

On my side my opinion is that, yes it would be great to fix this to have a better standard setup. So I'm not fully against this PR.

But the issue that I see right now is that we have a lot of important stuff to finalizes like Trixie, auto registration, security fixes and all other PR which is mostly finished, and to me we should prioritize this other this refactoring.

So maybe we can add a tag for this and as soon as we we are in a better state we can finish this PR and #2262

[Salamandar]

On my side my opinion is that, yes it would be great to fix this to have a better standard setup. So I'm not fully against this PR.

But the issue that I see right now is that we have a lot of important stuff to finalizes like Trixie, auto registration, security fixes and all other PR which is mostly finished, and to me we should prioritize this other this refactoring.

So maybe we can add a tag for this and as soon as we we are in a better state we can finish this PR and #2262

I fully agree, though I think it would be better to merge these refactoring PRs before releasing a new major version. But I'm okay to wait, your argument makes sense too.

[alexAubin]

But what are the arguments ? It's so annoying having tools not understanding the repo topology.

I made the initial change from src/yunohost/ to src/ a few years ago during one major debian upgrade because it is annoying to have this useless intermediate folder everytime you cd between folders etc. I'm guessing in the general case, python projects can have multiple packages in a single repo. But I don't understand why tools won't just handle the single-package case straight inside src/.

Personally I'm usually fine with just creating the symlink, and generally speaking i am tired of all the various changes in toolings all over the place and constant refactoring while Trixie is still pending, other important PRs are pending, 59 more PRs on this repo are pending, yet only ljf and some other folks sometimes joining the PRlanta session are trying to mop it up. This kind of stuff is just adding chaos while the team is struggling to keep up with the maintenance and have limited time, energy, brain bandwidth available.

[Salamandar]

I don't understand why tools won't just handle the single-package case straight inside src/.

Me neither, but python tools expect this and unless you want to patch them, that's how it is.

generally speaking i am tired of all the various changes in toolings all over the place and constant refactoring while Trixie is still pending, other important PRs are pending, 59 more PRs on this repo are pending

I don't know what to tell you except that i've been waiting and asking for help on the trixie subject for a year now and did not receive much.