Reputation: 7939
I am developing a Gtk application and would like to use a system-wide, installed version and run a different development version at the same time.
The application cannot be started twice because Gtk.Application
will try to connect to same DBus bus and refuse to be started twice. Therefore my idea is to determine whether I am in "development mode", i. e. the program has been installed using ./setup.py develop
, or not.
How can I achieve this? Or is there another, more general way to differ between development and installed versions of the program? I would prefer to avoid a special --develop
option or the like which would be useless outside of development scope.
Upvotes: 1
Views: 298
Reputation: 18908
Due to how setuptools
is designed the development mode is simply a transparent .egg-link
object away, so internally it is effectively impossible to determine whether or not the package is loaded as an egg-link
(i.e. development mode; relevant code here and see how it just recursively invoke find_distributions
which would in turn call this method again (through the internal import finder framework) before generating the metadata object).
So what you can do instead is to create a distinct DBus bus per version of your application. Typically for development your version number is different, and it is possible to pick up the version number through pkg_resources
API.
>>> pkg_resources.get_distribution('setuptools').version
'18.2'
You can also use it to generate custom metadata which is written to your package's egg-info, and through that it is possible for your package to declare custom items that could say customize the bus name of the Dbus bus to be used, but this will take a bit more work to set up. At the very least, you can declare a setup.cfg
that tag a build
[egg_info]
tag_build = dev
Rerun setup.py develop
again and the version number will include a dev
suffix which will show up in the version string returned by pkg_resources.get_distribution
on your package's name. This is not quite what you are looking for, but it might allow multiple versions of your application to be executed at the same time regardless of where they are installed or how they are installed. Consider users that might use virtualenvs to have multiple local installations of your applications and want to run them at the same time, and in that case you might want to base it on the hash of the install location instead:
>>> pkg_resources.get_distribution('setuptools').location
'/tmp/.env3/lib/python3.5/site-packages'
Of course, if the package is found within site-packages
it is probably done as a proper install
, but there is nothing in the API that will tell you this.
Upvotes: 2