[Distutils] Having a Python package install itself under a different name

[Lennart Regebro]

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 at 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.