Having a Python package install itself under a different name
Hello all! I want to ask you a question regarding something I want to do with my app. The reason I'm asking here is because I understand that Distribute somehow installs itself as "setuptools". (I've never looked into the details of it.) And I want something similar, so maybe you can advise me how to do it. I'm developing a package called `garlicsim`. The package is intended for Python 2.X, but I am also offerring Python 3 support on a different fork called `garlicsim_py3`.(1) So both of these packages live side by side on PyPI, and Python 3 users install `garlicsim_py3`, and Python 2 users install `garlicsim`. The problem is: When third party modules want to use garlicsim, they should have one package name to refer to, not two. Sure, they can do something like this: try: import garlicsim except ImportError: import garlicsim_py3 as garlicsim But I would prefer not to make the developers of these modules do this. Is there a way that `garlicsim_py3` will install itself under the alias `garlicsim`? What I want is for a Python 3 user to be able to `import garlicsim` and refer to the module all the time as `garlicsim`, but that it will really be `garlicsim_py3`. ---------- (1) I've reached the decision to support Python 3 on a fork instead of in the same code base; It's important for me that the code base will be clean, and I would really not want to introduce compatibilty hacks. Thanks, Ram Rachum.
On Fri, May 28, 2010 at 5:40 AM, cool-RR <cool-rr@cool-rr.com> wrote:
Hello all! I want to ask you a question regarding something I want to do with my app. The reason I'm asking here is because I understand that Distribute somehow installs itself as "setuptools". (I've never looked into the details of it.)
Your choice, but please do not do this. I really hate the behavior of distribute in that regard, and it has already wasted several hours of my time.
And I want something similar, so maybe you can advise me how to do it. I'm developing a package called `garlicsim`. The package is intended for Python 2.X, but I am also offerring Python 3 support on a different fork called `garlicsim_py3`.(1) So both of these packages live side by side on PyPI, and Python 3 users install `garlicsim_py3`, and Python 2 users install `garlicsim`. The problem is: When third party modules want to use garlicsim, they should have one package name to refer to, not two. Sure, they can do something like this: try: import garlicsim except ImportError: import garlicsim_py3 as garlicsim But I would prefer not to make the developers of these modules do this.
That's so much better than having some magic there. There are other solutions to your problem, but please, do not play with names like that. That's really not necessary. David
On Fri, May 28, 2010 at 12:25 AM, David Cournapeau <cournape@gmail.com>wrote:
On Fri, May 28, 2010 at 5:40 AM, cool-RR <cool-rr@cool-rr.com> wrote:
Hello all! I want to ask you a question regarding something I want to do with my app. The reason I'm asking here is because I understand that Distribute somehow installs itself as "setuptools". (I've never looked into the details of it.)
Your choice, but please do not do this. I really hate the behavior of distribute in that regard, and it has already wasted several hours of my time.
And I want something similar, so maybe you can advise me how to do it. I'm developing a package called `garlicsim`. The package is intended for Python 2.X, but I am also offerring Python 3 support on a different fork called `garlicsim_py3`.(1) So both of these packages live side by side on PyPI, and Python 3 users install `garlicsim_py3`, and Python 2 users install `garlicsim`. The problem is: When third party modules want to use garlicsim, they should have one package name to refer to, not two. Sure, they can do something like this: try: import garlicsim except ImportError: import garlicsim_py3 as garlicsim But I would prefer not to make the developers of these modules do this.
That's so much better than having some magic there. There are other solutions to your problem, but please, do not play with names like that. That's really not necessary.
David
Thanks for the advice David. If P.J.'s suggestion will work for me, I wouldn't have to take that route. The thing I want the most right now is anyone's opinion of what could possibly go wrong with the scheme that P.J. offered, before I start moving my codebase to it. Ram.
I just had an idea, no idea if it's good or not: You could try including both the Python 2 and Python 3 source code in the sdist, but select different ones for install depending on the Python version. I haven't tried this, but I can't come up with a reason it wouldn't work. If anyone else can, please tell me before Thursday. ;-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 On Thu, May 27, 2010 at 22:40, cool-RR <cool-rr@cool-rr.com> wrote:
Hello all! I want to ask you a question regarding something I want to do with my app. The reason I'm asking here is because I understand that Distribute somehow installs itself as "setuptools". (I've never looked into the details of it.) And I want something similar, so maybe you can advise me how to do it. I'm developing a package called `garlicsim`. The package is intended for Python 2.X, but I am also offerring Python 3 support on a different fork called `garlicsim_py3`.(1) So both of these packages live side by side on PyPI, and Python 3 users install `garlicsim_py3`, and Python 2 users install `garlicsim`. The problem is: When third party modules want to use garlicsim, they should have one package name to refer to, not two. Sure, they can do something like this: try: import garlicsim except ImportError: import garlicsim_py3 as garlicsim But I would prefer not to make the developers of these modules do this. Is there a way that `garlicsim_py3` will install itself under the alias `garlicsim`? What I want is for a Python 3 user to be able to `import garlicsim` and refer to the module all the time as `garlicsim`, but that it will really be `garlicsim_py3`. ---------- (1) I've reached the decision to support Python 3 on a fork instead of in the same code base; It's important for me that the code base will be clean, and I would really not want to introduce compatibilty hacks. Thanks, Ram Rachum.
On Fri, Jun 4, 2010 at 10:25 PM, Lennart Regebro <regebro@gmail.com> wrote:
I just had an idea, no idea if it's good or not:
You could try including both the Python 2 and Python 3 source code in the sdist, but select different ones for install depending on the Python version.
I haven't tried this, but I can't come up with a reason it wouldn't work. If anyone else can, please tell me before Thursday. ;-) -- Lennart Regebro
It would be pretty cool, since I won't have to confuse users with the `_py3` thing, but here are 2 problems: 1. I find it a little dirty that one single package has two different code bases. 2. I like having the Python 3 fork as an actual fork, (i.e. separate repo,) so I can easily merge changes from the main fork. If I keep them next to each other like this, it will be hard for me to keep them as separate repos and therefore hard to do merges. (Keep in mind that the main fork contains three packages, `garlicsim`, `garlicsim_lib` and `garlicsim_wx`, and the Python 3 fork contains `garlicsim` and `garlicsim_lib`, so trying to weave them together will be nontrivial.) Sure, I can figure out some scheme to do this, but it will be messy. Ram.
On Fri, Jun 4, 2010 at 22:36, cool-RR <cool-rr@cool-rr.com> wrote:
It would be pretty cool, since I won't have to confuse users with the `_py3` thing, but here are 2 problems: 1. I find it a little dirty that one single package has two different code bases.
Well, sure, but having two packages is also dirty. :-) It's a matter of taste.
2. I like having the Python 3 fork as an actual fork, (i.e. separate repo,) so I can easily merge changes from the main fork. If I keep them next to each other like this, it will be hard for me to keep them as separate repos and therefore hard to do merges.
Aha, so you use mercurial or? It's hard to do merges between folders there? I'm used to svn, where that wouldn't be a problem. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64
On Sat, Jun 5, 2010 at 7:22 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Jun 4, 2010 at 22:36, cool-RR <cool-rr@cool-rr.com> wrote:
It would be pretty cool, since I won't have to confuse users with the `_py3` thing, but here are 2 problems: 1. I find it a little dirty that one single package has two different code bases.
Well, sure, but having two packages is also dirty. :-) It's a matter of taste.
2. I like having the Python 3 fork as an actual fork, (i.e. separate repo,) so I can easily merge changes from the main fork. If I keep them next to each other like this, it will be hard for me to keep them as separate repos and therefore hard to do merges.
Aha, so you use mercurial or? It's hard to do merges between folders there? I'm used to svn, where that wouldn't be a problem.
-- Lennart Regebro
I probably won't take this approach, but thank you Lennart for the tip. Ram.
participants (3)
-
cool-RR -
David Cournapeau -
Lennart Regebro