On Thu, Nov 21, 2013 at 1:32 PM, Christian Tismer <tismer@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@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@noaa.gov