How to use this when I package all into a package and installed in local virtual env?

[iScheme4U]

This utility works fine when I am using it in development env, but when I package my project and install to my local virtual env, it will complain following:

ImportError: cannot import name 'config' from 'config2.config'.

Looks like it cannot find the configuration files, how can I solve this problem?

Thanks

[bjoluc]

Hi there,
to me, it looks like config2 is not installed along with your package. Do you define it as a requirement in your setup.py? If you'd like to get rid of the manual setup.py stuff, I can highly recommend Poetry for packaging. You could just poetry add config2 then and it should work (if the problem is not config2-related).

One problem in this regard is #17, so bear in mind that, by adding config2 as a dependency, your package also depends on lots of development dependencies of it, unfortunately. If you find any other config2-oddities (like I did), you may check out appcfg which takes a similar, slightly less magical, but more stable approach (and has 100% test coverage). I made this to overcome the shortcomings of config2 (which seems to be stale).

EDIT: The devel's in detail; misread the ImportError, sorry! I guess you are right with your assumption, and I also guess this is due to the stack inspection magic in config2. I was experiencing something similar a year or so ago. Should work with appcfg!

[iScheme4U]

Hi there,
I double checked that i have included the library in my setup, like I said, it works fine in development, but it will complain the fore mentioned error.
Looks like it cannot find the configuration files, so it cannot create the config object, so ImportError occurred.

[bjoluc]

I remember I had a related problem about a year ago. It seemed to me like the stack inspection would fail to retrieve the proper config path. Maybe it was also related to rootpath not finding the right directory. Another related problem that I had with config2 was that it would not work if applied in multiple packages at the same time. I solved these issues in appcfg by explicitly passing __name__, and then just using the builtin importlib utils to infer the path. This also enables other packages (such as tests) to retrieve the configuration of a specific package via the package name. I generally prefer explicit over implicit in those cases (why should we try to infer information that is already available via __name__).