Configure auto-import to omit src from import statements

[daria-shaw]

Is your feature request related to a problem? Please describe.
I work in python projects that use poetry for dependency management, and use a src/ folder for the repository. When importing an anything from within the repo, rope defaults to importing relative to the root directory, instead of from the package source.
e.g.

from src.REPO.x import y

Describe the solution you'd like
I'd like to be able to set a configuration for rope (eg in pytool.toml) to tell Rope to not reference the src in the import, and instead just use the repo name.
e.g.

from REPO.x import y

Describe alternatives you've considered
See discussion in pylsp: python-lsp/python-lsp-server#525

I've experimented with changing the existing config of python_files and source_folders, but this hasn't given much success.

Additional context
I use rope as part of pylsp.

[daria-shaw]

I've created a repo to show an example of what currently happens when using rope in pylsp for importing a function:
https://github.com/daara-s/poetry-repo-example/tree/master/my-package

[bagel897]

It'd be better to have it automatically use another venv path. You can probably do this in pylsp by editing the rope config.

[lieryan]

pytool.toml is global config file, unless you want this to be applied to all of your projects (which is unlikely), you'll likely want to use a local config file for this purpose, rope reads [tool.rope] section in pyproject.toml but projectroot is given by the integration (pylsp in this case) rather than something you can configure from pyproject.toml.

Maybe rope could read poetry's section in pyproject.toml to find the real application's root? The Project(projectroot) is where you might want to poke around to see if setting the projectroot as projectroot (from editor/lsp server) / src_path_from_pyproject_toml might work.

[fast-90]

Maybe rope could read poetry's section in pyproject.toml to find the real application's root?

I am a bit skeptical about this idea as Poetry's pyproject.toml structure does not comply with e.g. PEP 621, thereby making such a solution really specific to Poetry (which not everyone is using).

I think a better solution would be to introduce a new config in pytool.toml / [tool.rope] (if using pyproject.toml) which is something like project_root, where the user can be specific about which directory they want to use as the project root for rope. Alternatively, you can also make src the project root by default if it exists since I believe it is a sufficiently commonly used layout, but then again you would have to make some assumptions again about how people structure their repo.

@lieryan please let me know what you think, I'm happy to take a first stab if you like any of my ideas.

[last-partizan]

I think, best possible solution is to require 0 setup effort from the user.

• Try PEP 621 metadata
• Try [tool.rope]
• Try $PYTHONPATH, maybe that's a project root. (I already have it configured for some other tools)
• Try parsing poetry-specific fields in pyproject.toml

Sure, it's adding few extra lines of code, but it just works for thousands of users.

[lieryan]

Hi thanks everyone for the interest in this idea. I think it makes sense to read PEP621 metadata to get the project root structure. Reading Poetry metadata can be implemented as well as a fallback source of configuration, if there's anyone interested in it, but I agree that if we implement both, PEP621 should take higher precedence.

@fast-90 feel free to pick up PEP621 project root support, with or without Poetry, if you want to take a stab at implementing this.

I'm not a big fan of having a default list of directories like src that are just being automagically picked up without any explicit settings by the user, but I am not completely against it either. I think a default src should not be implemented yet for now, but if there's enough people wanting it, please make yourself heard and we can reconsider this.

[GereonV]

I think src should definitely work somehow and without setup, because this project-structure seems to be the officially recommended one