path info according to __file__

[jinserk]

Hi,

Above all, thank you for sharing this great package.
I have a setting according to the __file__, but the file location is not based on the file itself, but the include calling file. For example, when I have setting files as:

settings.__init__.py
settings/components/__init__.py
settings/components/common.py
settings/components/others.py

and if assume that include is calling components/common.py that contains the __file__ based setting. I expected the __file__ == settings/components/common.py but the actual value is settings.__init__.py.

if I have another setting in components/others.py and need to import from settings.components.common import VARS where the VARS is the setting based on __file__, then the value of the VARS becomes different.

Can I have any hint to solve this conflict? Thank you!

[sobolevn]

Sorry, I don't understand your problem 😞

Can you please post a reproduction? I guess a separate github repo would be the best form here.

[jinserk]

I have no public github so let me explain a little bit more detail here:

dirs/files structure:

settings/__init__.py
settings/components/__init__.py
settings/components/common.py
settings/components/apps.py
settings/environments/__init__.py
settings/environments/development.py

__
settings/__init__.py:

from split_settings.tools import include, optional

# Include settings:
base_settings = [
    'components/common.py',
    'components/apps.py',
    'environments/developement.py',
]

include(*base_settings)

__
settings/components/apps.py:
...
from pathlib import Path
...
VAR1 = Path(__file__).parent.joinpath('components', 'app_list.txt')
print(VAR1)

VAR2 = 'something'
# doing something with VAR2 here
...

__
settings/environments/__init__.py:

from settings.components.apps import VAR2

# doing another thing with VAR2 here

In this configuration, the components/apps.py will be imported twice; from settings/__init__.py and from settings/environments/__init__.py. When I run using this configs, I've got the VAR1 printouts like:

.../settings/components/app_list.txt                                                                                                                                                                                                           
.../settings/components/components/app_list.txt                

I hope this will be sufficient to explain my issue. Thank you!

[VKFisher]

I'm experiencing the same issue. Here's the problem as I understand it:

Let's say I have project/settings/components/module_one.py which contains

my_path = Path(__file__).parent

And I also have project/settings/components/module_two.py with

from project.settings.components.module_one import my_path

my_other_path = my_path

Now, when include('components/*.py') is executed inside project/settings/__init__.py:

• we execute the contents of module_one.py in the context of the project/settings/__init__.py, so the value of my_path becomes project/settings

• we execute the contents of module_two.py, also in the context of the project/settings/__init__.py. However, since we import module_one from its original location, __file__ now evaluates to project/settings/components/module_one.py, so the value of my_other_path becomes project/settings/components

For now I work around the problem by fixing all paths that are calculated relative to __file__ in project/settings/__init__.py after include() is executed.

[Rydra]

I just came across this issue and I noticed that the variables that are processed by the include function of the library are included in the global variables. So:

settings/environments/__init__.py:

from settings.components.apps import VAR2

# doing another thing with VAR2 here

Would just be:

settings/environments/__init__.py:

# doing another thing with VAR2 here

Without the import, and you'll have VAR2 available even if you do not import it. And no double import.

However bear in mind that if you have an IDE or mypy in place it's gonna complain, so that's not too clean either.