[Python-Dev] PEP 0404 and VS 2010

[Chris Barker]

On Thu, Nov 21, 2013 at 1:32 PM, Christian Tismer <tismer at stackless.com>wrote:

>  I am converted to an OS X developer since 2006, but never had ABI
> problems,
> because I use homebrew,
>

Right, different story -- you are supposed to compile everything on the
target system, so everything stays compatible.

but instead of being set free on Windows after 30 years
> of pain, I now have the same mess in my Parallels VMs.
> Customers are so cruel, aren't they?
>

business would be som much easier without them [but less successful ;-) ]

Do you want people to be able to use extensions built by third parties for
> python.org CPython with your binary builds?
>
> Would be great, but I would not mind to create their extensions on
> stackless.com, instead.
>
The other potential route for error is a pip install -- you don't want pip
> to find a binary that is incompatible with your build -- so you should
> assure that whatever pip/wheel uses to identify the build is
> set differently in your build (see the relevant PEPs).
>
>
> Yes, I want to make PIP work with it, want to make it very simple to
> install
> whatnot, and let people use that stuff. So if you can, please teach me
> what I need to do or avoid.
>

I think it's a "simple" as making sure that the names your binary generate
for pip and wheel is different than the python.org VS2008 build. That way,
if someone does "pip install something" with your binary, it won't
accidentally download a binary wheel, but rather will try to install from
source. And if their complier is set up right, that should work (ignore
dependency hell for now).

And you could build wheels and host them on the stackless site for things
that aren't easy to build.

folks could still get in trouble trying to install msi installers built for
pyton,org python -- but it sounds like you could fix that with a dll name
change.

What I want is a workable CPython path for some customer (!=CCP) to use
> for the next (maybe 5) years, and I want to build that now, for good.
>

That's the trick -- I don't think it's only me that thinks we should have
the option, some point in the future, to put out VS_something_else binary
of Python2.7, or a future version.

So it would be nice to come to a consensus on the pip/wheel/dll naming
scheme before you put anything out.

 On Thu, Nov 21, 2013 at 1:31 PM, Daniel Holth <dholth at gmail.com> wrote:

> As for wheel it actually does support an ABI tag that is separate from
> the Python version and the architecture. It's the second one
> pyversion-abi-architecture as in py27-none-any or py27-cp27-linux_i386
> (spelling?). The build tool and installer would have to be modified to
> be aware of any newly defined ABI tags.


I'm still confused a bit about ABI vs. Platform vs. I had thought that ABI
meant the ABI defined by the python source code, rather than the
ABI defined by the complier -- the examples in the doc imply that.

As for "platform", I'm not sure how to define that, but it seems reasonable
to consider the run-time core Clib as part of the "platform". In any case,
that's what the Mac builds are doing.

But it really doesn't matter which you use, as long as there is
some consistency.

Maybe this part is a topic for the distutils-sig.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131121/7e01353d/attachment.html>