🔒 need help with venv/local package/relative import

[fringe aurora]

I tried for several days, and can't because python's relative import system is made terribly.
I know there exists 3 solutions:

• relative imports (that are deprecated now)
• hacky way of modifying path (which i don't even consider)
• using venv, editable/dev mode, installing as a local package and importing - I tried, i failed, it just simply doesn't work, and i don't understand it. I don't want to have pyproject.toml or setup.py or any other config, i just simply want to treat particular inner folder in hierarchy as a standalone "package" with init and main

[jolly zodiac]

@fringe aurora

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[fringe aurora]

want someone to help me and take through steps i need todo from start to finish

to achive my goal

[past robin]

Hey, you should try and call the core module by importing it as :

from backend import core

because the error suggest that core is not detected as a module, but an attribute of the core object

[fringe aurora]

can you specify exactly what/where/how

about what file are you talking about

[past robin]

in server.py

[slim tangle]

Hey I'm not here to help but I need* help...how do I make the link to paste the code

[keen charm]

It's considered rude to interrupt someone else's thread

[slim tangle]

Sry

[past robin]

use thos at start and end of the message```

[fringe aurora]

create own post and go out of mine

[slim tangle]

Ok sry

[keen charm]

To clarify your main is in a subdirectory? And your backend is in a parent?

[past robin]

in server.py change the import statement to :

from backend import core

[fringe aurora]

i want everything to be either standalone or work as a group

[fringe aurora]

why?

its just the other way of writing thing

[keen charm]

That doesn't really answer my question

[past robin]

try it, because the error suggest core isn't detected as a module but an attribute of the backend object. that's my hypothesis

[fringe aurora]

i want to be able to run backend folder (cuz it has __main__.py with python .), but also be able to run server folder, while being inside it and writing python .

[fringe aurora]

here's core
core should work just fine

its not the problem

[keen charm]

It looks to me like you have the following structure:

> Project
>> Backend
>> backend.py
>>> Core
>>> Main.py

[fringe aurora]

i need a solution with venv

[fringe aurora]

here's the project structure

each folder should be able to run on its own and be imported as a local package

with relative imports based on local package starting position

it is being achieved with venv

https://stackoverflow.com/questions/16981921/relative-imports-in-python-3

[keen charm]

If core/__main__.py is what you are running... It won't be able to "back up" a directory and access backend

[fringe aurora]

why?

[keen charm]

Attachments aren't allowed here

The bot will yeet them

[fringe aurora]

rename it to 7z

here's a project

take a look yourself

each file is empty mostly

its just a test project

kind of

okay lemmy make much simpler example

here's new example

here's code

how do i make them relative imports

[brazen geyser]

from . import c

[fringe aurora]

without doing something like

[fringe aurora]

no

[brazen geyser]

no?

oh, it's c.c

so from .c import c

[fringe aurora]

cuz i want to be able to run these files standalone

[brazen geyser]

eh

[fringe aurora]

like this

[fringe aurora]

and if there will be b.c it wont work

[brazen geyser]

why not create a proper package structure and then do python -m a.b.c or something

[fringe aurora]

wdym proper?

[brazen geyser]

relative imports are pretty pointless if you don't have a package structure in the first place

well, a package is a directory with an __init__.py

relative imports work within a package structure

[fringe aurora]

i h a d i t

its just an example

for yall

to not add unnessesary files for complexity

if you want proper structure, take a look at the original example

[brazen geyser]

well they're pretty necessary for relative imports to work

[fringe aurora]

okay

ill do what u want

[fringe aurora]

and the c (forgot to include)

[sinful bluff]

there's nothing deprecated about relative imports, but you should stick to a consistent working directory because that has a significant (yet non-obvious) effect on import statements

generally if you're making a package that can be used without installation, you should avoid using an src/ directory: py project/ ├── package/ │ ├── subpackage/ │ │ ├── __init__.py │ │ │ from . import mod_a # Relative │ │ │ from package import mod_b # Absolute │ │ ├── __main__.py │ │ └── mod_a.py │ ├── __init__.py │ │ from . import subpackage # Relative │ │ from package import mod_b # Absolute │ └── mod_b.py └── main.py from package import subpackage to run main.py, you can simply use python path/to/main.py, but if you have to run the package or one of its submodules directly, your CWD determines how package can be imported, including your import statements, so you need to set your CWD to just outside package and run it with -m: sh /project $ python -m package.subpackage
as for installable packages, it's arguably simpler because your build system adds the package to your venv, for example: ```toml
project/
├── .venv/
├── src/
│ └── package/
│ ├── subpackage/
│ │ ├── init.py
│ │ └── mod_a.py
│ ├── init.py
│ └── mod_b.py
└── pyproject.toml
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

    [project]
    name = "my-project"
    version = "1.0.0"
    # Nothing else required, setuptools will find
    # src/package by itself``` once you've installed your package into your environment, you can import it from anywhere regardless of CWD: ```sh

(.venv) /project $ pip install --editable .
...
Installed my-project-1.0.0
(.venv) /project $ cd /somewhere/else
(.venv) /somewhere/else $ python -c "import package" # Valid
(.venv) /somewhere/else $ python -m package.submodule # Valid```

[fringe aurora]

i'm gonna recreate your example

to try myself

[sinful bluff]

more technically, the goal of both approaches is to make your package appear in a subdirectory of sys.path, a list of directories that python searches for modules to import; in the case of python main.py and python -m package.submodule, they rely on prepending project/ to sys.path to find the package subdirectory, but if you pip install it instead, your package is added to your venv's site-packages/ which is always included in sys.path, hence why you can still import the package after cding to another directory

[fringe aurora]

thank you 💜
i understood now how pip install --editable . and pyproject.toml works together

i thought pip install --editable will be installed somewhere in root of python folder, and not inside the project folder, so i thought i need somehow to use venv to fix this

while it works on its own

[sinful bluff]

this post i wrote also might help you understand sys.path too
https://thegamecracks.github.io/python/syspath.html#how-do-python-imports-work
(see the .venv site-packages/ in there? that's where pip installs your package to)

[jolly zodiac]

Python help channel closed

This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered, feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.