Hi Distutils folks, I'm kind of a lurker here, due primarily to the fact that I'm too swamped with various other things to materially contribute to the effort, but I've been lurking for some time hoping to learn enough to avoid troubling anyone with pesky questions. In that respect I've apparently failed, because here comes the question! Background: I'm helping out with a python package: vpython <http://vpython.org> and I'm also teaching an intro scientific computing class this spring. I'm mostly a Mac/Linux user, but my students are often windows users. I would love to permit my students to use enthought/canopy and/or continuum analytics (C.A.) along with vpython. At the moment we're creating binary releases of vpython for windows and mac and posting them on sourceforge <https://sourceforge.net/projects/vpythonwx/>. Bruce has been building the windows binary using VC (no setup.py) in a way that's compatible withpython.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux. I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions. I'd love to figure out how to build vpython under this system so that my windows users could use them together transparently. (BTW is this the same 'anaconda' that has been discussed on this list recently, or is that something different?) I'm pretty sure I could work out how to build vpython with continuum analytics on the mac (which means building boost + wxPython using the C.A. python). Questions: Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py? (I've noticed the recent conversation about binary dependencies, but from the discussion it seemed to be mostly about the future...) Where should I go to get the 'latest' advise/documentation on distribution for a package that I want to distribute today (rather than pestering you folks)? thanks! -steve (P.S., I tried to send this earlier today, but it appears to have failed. Apologies if you've gotten this twice) Steve Spicklemire University of Indianapolis Dept. of Physics and Earth Space Sciences spicklemire@uindy.edu (317) 788-3313
On Mon, Jan 6, 2014 at 12:26 PM, Steve Spicklemire <steve@spvi.com> wrote:
avoid troubling anyone with pesky questions. In that respect I've apparently failed, because here comes the question!
I think this is a use case that is quite useful for us all to chew on a bit... 1st -- yes "Anaconda" refers to the distribution from Continuum. Note that "conda" is the packaging system that Anaconda uses, but it can also be used independently of the distribution.
I'm helping out with a python package: vpython <http://vpython.org>
[side note: fairly recently a por tof VPython to wxPython was done -- is that what you are using? Notable because I think wxPython is still not available for Anaconda...)
and I'm also teaching an intro scientific computing class this spring. I'm mostly a Mac/Linux user, but my students are often windows users. I would love to permit my students to use enthought/canopy and/or continuum analytics (C.A.) along with vpython.
Either/or? As an instructor, I'd recommend you pick one and go with it -- if you need wx, that means Canopy for now. Alternatively, you suggest the python.org builds, and point your users to binaries they can get elsewhere (Chris Gohlke's site for Windows...) At the moment we're creating binary releases of vpython for windows and mac
and posting them on sourceforge < https://sourceforge.net/projects/vpythonwx/>.
Are these for the python.org builds? good for you! Bruce has been building the windows binary using VC (no setup.py) in a way
that's compatible withpython.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux.
Why not distutils for building Windows? I find it really helpful.
I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions.
I think Canopy does that too -- at least it did a few years ago. but I _think_ you can build extensions with either MinGW or MSVC for the same binary python -- if it's set up right ;-) I'd love to figure out how to build vpython under this system so that my
windows users could use them together transparently.
You want to take a look at conda: https://github.com/pydata/conda If you can build a conda recipe then you are set to go... That being said, it is supposed to be a goal for Anaconda to be binary compatible with the python.org binaries -- so you may well be able to build the way you are, and give the users a way to install it into Anaconda. In theory, binary wheels are the way to do this. I'm pretty sure I could work out how to build vpython with continuum
analytics on the mac (which means building boost + wxPython using the C.A. python).
ahh -- you are using wx -- I'd check with the CA folks and see where they are at -- they said they were working on a wxPython package....and I'm sure they'd like help and testing...
Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py?
no -- except by hand with custom code. I'm still a little unclear on your goals here. If you want to simple be able to tell your students to use Anaconda then look into conda and the CA help lists -- and conda is more or less designed to solve these sorts of problems. also, the odds are good that Anaconda already has boost, and if not someone has done a conda recipe for it: https://github.com/faircloth-lab/conda-recipes/tree/master/boost If you want your users to be able to use any of: Anaconda Python.org python Canopy Then I'd look into building binary wheels, and see if you can get them to work with Anaconda and Canopy. Note: distutils does not address the third-party non-python dependency problem -- conda tries does address it (though still not clear to me if it helps you build them...) You may also want to look at Gattai, which aims to help you build them: http://sourceforge.net/projects/gattai/ HTH, -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
Thanks Chris for the detailed reply. On Jan 6, 2014, at 4:55 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Either/or? As an instructor, I'd recommend you pick one and go with it -- if you need wx, that means Canopy for now. Alternatively, you suggest the python.org builds, and point your users to binaries they can get elsewhere (Chris Gohlke's site for Windows...)
Right. My impression is/was that python.org/CA/Canopy were all different builds of python that were *not* interoperable. So that a binary built with one could not generally be expected to work with another. If that's not true, then maybe this is a non-problem. I guess I should just "try it" and see what happens.
At the moment we're creating binary releases of vpython for windows and mac and posting them on sourceforge <https://sourceforge.net/projects/vpythonwx/>.
Are these for the python.org builds? good for you!
Yes they are for the python.org builds.
Bruce has been building the windows binary using VC (no setup.py) in a way that's compatible withpython.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux.
Why not distutils for building Windows? I find it really helpful.
I don't even have a 'real' windows system (only VirtualBox) and I don't have VC Studio, so Bruce has been doing all the windows work (he's got code that creates an installer that's been working for years). My attempt at a setup.py for windows didn't work for him, and I have limited ability to debug it myself. If I could get MinGW to work with my setup.py, maybe I could get things going. I just wanted to get some confirmation that it was a reasonable plan before I wasted a lot of time on what might turn out to be a dead end. Also, I've built wxPython on the mac from source multiple times so that I could turn on debug symbols. Do you think the build-wxpython.py script would work under windows with MinGW? I guess that's probably kind of a naive hope. ;-)
I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions.
I think Canopy does that too -- at least it did a few years ago. but I _think_ you can build extensions with either MinGW or MSVC for the same binary python -- if it's set up right ;-)
As before, maybe this is a non-problem that I should just try it. That'll be step 1. ;-)
I'd love to figure out how to build vpython under this system so that my windows users could use them together transparently.
You want to take a look at conda:
https://github.com/pydata/conda
If you can build a conda recipe then you are set to go...
That being said, it is supposed to be a goal for Anaconda to be binary compatible with the python.org binaries -- so you may well be able to build the way you are, and give the users a way to install it into Anaconda. In theory, binary wheels are the way to do this.
I'm pretty sure I could work out how to build vpython with continuum analytics on the mac (which means building boost + wxPython using the C.A. python).
ahh -- you are using wx -- I'd check with the CA folks and see where they are at -- they said they were working on a wxPython package....and I'm sure they'd like help and testing...
Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py?
no -- except by hand with custom code.
I'm still a little unclear on your goals here.
Well I guess I am too. I was impressed with CAs ability to use 'pip' on windows to install plotly right away. It's almost like working in unix. I liked that! It would be a dream if a student, after installing the CA distribution could type: /anaconda/bin/pip install vpython and it would "just work". I understand that's impossible at the moment. But if I could create instructions and/or build a set of binary files a student could easily install that would give them: 1) vpython 2) matplotlib 3) ipython 4) scipy I'd be ecstatic. I'll also check Chris Gohlke's site. Maybe I don't need all the bells and whistles of Canopy/CA etc.
If you want to simple be able to tell your students to use Anaconda then look into conda and the CA help lists -- and conda is more or less designed to solve these sorts of problems. also, the odds are good that Anaconda already has boost, and if not someone has done a conda recipe for it:
https://github.com/faircloth-lab/conda-recipes/tree/master/boost
If you want your users to be able to use any of:
Anaconda Python.org python Canopy
Then I'd look into building binary wheels, and see if you can get them to work with Anaconda and Canopy.
Note: distutils does not address the third-party non-python dependency problem -- conda tries does address it (though still not clear to me if it helps you build them...) You may also want to look at Gattai, which aims to help you build them:
OK. Thanks so much! I appreciate your pointers. I'll let you know what I discover. Ultimately I'd like to help Bruce package vpython in such a way that folks can use 'pip' to include wx and vpython in whichever python distribution they happen to choose without a lot of fuss. thanks, -steve
HTH, -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
On Mon, Jan 6, 2014 at 3:20 PM, Steve Spicklemire <steve@spvi.com> wrote:
Thanks Chris for the detailed reply.
Well, I'm trying to sort out similar issues myself.... Right. My impression is/was that python.org/CA/Canopy were all different
builds of python that were *not* interoperable.
well, in the case of Anaconda, Travis told me the intent was that it would be -- the reality, I'm not sure about.
So that a binary built with one could not generally be expected to work with another. If that's not true, then maybe this is a non-problem. I guess I should just "try it" and see what happens.
it's still tricky to get things to install correctly -- the Windows (and Mac) installers expect python to be in a particular location -- Anaconda is not there.
Why not distutils for building Windows? I find it really helpful.
I don't even have a 'real' windows system (only VirtualBox) and I don't have VC Studio,
you should be able to do it with the free visual studio express 2008. A bit hard to find an installer these days, but I think it's still there. I've had much better luck with that than MinGW. Do you think the build-wxpython.py script would work under windows with
MinGW? I guess that's probably kind of a naive hope. ;-)
I doubt it --- but again VS2008 Express might build it OK -- but then Robin provides installers for wx anyway.
Well I guess I am too. I was impressed with CAs ability to use 'pip' on windows to install plotly right away. It's almost like working in unix. I liked that!
is plotly pure python? in that case, then it's pretty easy, really. /anaconda/bin/pip install vpython
pip install with compiled binaries is a different beast -- I _think_ pypi is now set up to find binary wheels that match the python.org python. I have no idea if those will install under Anaconda. But you probably want "conda install vpython" if you want Anaconda anyway.
and it would "just work".
I understand that's impossible at the moment. But if I could create instructions and/or build a set of binary files a student could easily install that would give them:
1) vpython 2) matplotlib 3) ipython 4) scipy
we're pretty close to having all these as binary wheels now. There isn't much stopping it. vpyton is up to you. But wx is not there -- though if you can get it to build on Windows, making a wheel of it should be easy. I imagine Robin would be happy to put them up in PyPi. I'd be ecstatic. I'll also check Chris Gohlke's site. Maybe I don't need
all the bells and whistles of Canopy/CA etc.
That is a GREAT resource! Ultimately I'd like to help Bruce package vpython in such a way that folks
can use 'pip' to include wx and vpython in whichever python distribution they happen to choose without a lot of fuss.
It's not really a full-on goal for Anaconda or Canopy to be fully pip compatible -- so that may be a bit of a fantasy... Also: you can point pip at a custom "wheelhouse" -- i.e. a collection of wheels that you put together. In your position, I"d be tempted to provide a full set of wheels for the python.org build for everything that you need that isn't already pip-installable. Then point your students to that. If you're lucky, those some wheels may work with Anaconda, or even Canopy. -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
On Mon, Jan 6, 2014 at 9:55 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Mon, Jan 6, 2014 at 12:26 PM, Steve Spicklemire <steve@spvi.com> wrote:
avoid troubling anyone with pesky questions. In that respect I've apparently failed, because here comes the question!
I think this is a use case that is quite useful for us all to chew on a bit...
1st -- yes "Anaconda" refers to the distribution from Continuum. Note that "conda" is the packaging system that Anaconda uses, but it can also be used independently of the distribution.
I'm helping out with a python package: vpython <http://vpython.org>
[side note: fairly recently a por tof VPython to wxPython was done -- is that what you are using? Notable because I think wxPython is still not available for Anaconda...)
and I'm also teaching an intro scientific computing class this spring. I'm mostly a Mac/Linux user, but my students are often windows users. I would love to permit my students to use enthought/canopy and/or continuum analytics (C.A.) along with vpython.
Either/or? As an instructor, I'd recommend you pick one and go with it -- if you need wx, that means Canopy for now. Alternatively, you suggest the python.org builds, and point your users to binaries they can get elsewhere (Chris Gohlke's site for Windows...)
At the moment we're creating binary releases of vpython for windows and
mac and posting them on sourceforge < https://sourceforge.net/projects/vpythonwx/>.
Are these for the python.org builds? good for you!
Bruce has been building the windows binary using VC (no setup.py) in a way
that's compatible withpython.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux.
Why not distutils for building Windows? I find it really helpful.
I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions.
I think Canopy does that too -- at least it did a few years ago. but I _think_ you can build extensions with either MinGW or MSVC for the same binary python -- if it's set up right ;-)
We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble. We do provide mingw so that people can build extensions without depending on MS toolchain, but that's not a setup I would recommend in general. It works well for extensions that don't depend much on the C runtime (numpy is a good example), but as soon as you manipulate IO, etc... you encounter issues linked to ABI incompatibilities between what you get from the python runtime and mingw. David
I'd love to figure out how to build vpython under this system so that my
windows users could use them together transparently.
You want to take a look at conda:
https://github.com/pydata/conda
If you can build a conda recipe then you are set to go...
That being said, it is supposed to be a goal for Anaconda to be binary compatible with the python.org binaries -- so you may well be able to build the way you are, and give the users a way to install it into Anaconda. In theory, binary wheels are the way to do this.
I'm pretty sure I could work out how to build vpython with continuum
analytics on the mac (which means building boost + wxPython using the C.A. python).
ahh -- you are using wx -- I'd check with the CA folks and see where they are at -- they said they were working on a wxPython package....and I'm sure they'd like help and testing...
Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py?
no -- except by hand with custom code.
I'm still a little unclear on your goals here. If you want to simple be able to tell your students to use Anaconda then look into conda and the CA help lists -- and conda is more or less designed to solve these sorts of problems. also, the odds are good that Anaconda already has boost, and if not someone has done a conda recipe for it:
https://github.com/faircloth-lab/conda-recipes/tree/master/boost
If you want your users to be able to use any of:
Anaconda Python.org python Canopy
Then I'd look into building binary wheels, and see if you can get them to work with Anaconda and Canopy.
Note: distutils does not address the third-party non-python dependency problem -- conda tries does address it (though still not clear to me if it helps you build them...) You may also want to look at Gattai, which aims to help you build them:
http://sourceforge.net/projects/gattai/
HTH, -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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com> wrote:
We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds? i.e would the same binary wheel work for both? -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
On Wed, Jan 8, 2014 at 6:44 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com>wrote:
We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds?
i.e would the same binary wheel work for both?
It should, and we will fix issues if they come up. David
-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
This is good news. I'll experiment! thanks, -steve On Jan 8, 2014, at 1:48 PM, David Cournapeau <cournape@gmail.com> wrote:
On Wed, Jan 8, 2014 at 6:44 PM, Chris Barker <chris.barker@noaa.gov> wrote: On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com> wrote: We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds?
i.e would the same binary wheel work for both?
It should, and we will fix issues if they come up.
David
-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
So, related question: Should the Mac binaries also work with the python.org mac build? Regarding my quest: I just punted for now (out of time, need something working by Monday). I'm using Christoph Gohlke's binaries for windows (seem to work well!) and cooked up my own custom installer for Mac that loads on top of python.org python and our current VPython installer. All working, so crisis averted. ;-) I'll look into binary wheels when the dust settles. thanks for all the suggestions! -steve On Jan 8, 2014, at 2:09 PM, Steve Spicklemire <steve@spvi.com> wrote:
This is good news. I'll experiment!
thanks, -steve
On Jan 8, 2014, at 1:48 PM, David Cournapeau <cournape@gmail.com> wrote:
On Wed, Jan 8, 2014 at 6:44 PM, Chris Barker <chris.barker@noaa.gov> wrote: On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com> wrote: We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds?
i.e would the same binary wheel work for both?
It should, and we will fix issues if they come up.
David
-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
On Thu, Jan 9, 2014 at 10:43 PM, Steve Spicklemire <steve@spvi.com> wrote:
So, related question: Should the Mac binaries also work with the python.org mac build?
Binary compatibility is best achieved on windows: the platform makes it easier, and it is so painful to build stuff there that it would be insane for vendors not to be compatible. Mac is a whole different story. First, you have frameworks vs non frameworks builds, and compilers/dev environments keep changing in incompatible ways: you have gcc, gcc-llvm, clang, SDK which are tied to xcode versions themselves tied to OS versions, it is a mess :) Case in point, the python.org binaries are generally not compatible with the system python provided by Apple (that is you can't use an installer made for one with the other). At least in the scientific community, we generally provide binaries for python.org, and I think it is good practice to avoid touching the system python. David
Regarding my quest: I just punted for now (out of time, need something working by Monday).
I'm using Christoph Gohlke's binaries for windows (seem to work well!) and cooked up my own custom installer for Mac that loads on top of python.orgpython and our current VPython installer. All working, so crisis averted. ;-)
I'll look into binary wheels when the dust settles.
thanks for all the suggestions! -steve
On Jan 8, 2014, at 2:09 PM, Steve Spicklemire <steve@spvi.com> wrote:
This is good news. I'll experiment!
thanks, -steve
On Jan 8, 2014, at 1:48 PM, David Cournapeau <cournape@gmail.com> wrote:
On Wed, Jan 8, 2014 at 6:44 PM, Chris Barker <chris.barker@noaa.gov>
wrote:
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com> wrote: We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds?
i.e would the same binary wheel work for both?
It should, and we will fix issues if they come up.
David
-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
What David said, plus: On Thu, Jan 9, 2014 at 10:43 PM, Steve Spicklemire <steve@spvi.com> wrote:
So, related question: Should the Mac binaries also work with the python.org mac build?
Not sure what "also" is respect to, but the pyton.org builds are a good common denominator: The Apple builds have their issues: - Apple never upgrades them - You can't re-distribute them (build stuff with Py2app) .. at least without violating copyright. While it's appealing for people to not have to install anything, if they are installing 3rd party packages they are installing stuff, son one extra install at the start is not a big deal. So: if you are going to support one binary -- it should be the python.orgone. It is a bit of a pain to build binaries for the Python.org builds, as they are universal and support older OS versions. Personally, I think we should address this by: 1) having a centralized project for building varios binary dependencies that are compatible with the python.org builds -- why should multiple package distributors all have to figure out how to build, e.g. freetype correctly? I've created a repo for this, but haven't gotten far: https://github.com/MacPython/osxinst let me know if you are interested in contributing. 2) Maybe it's time to put out an "official" python.org build that's simpler: perhaps 10.7+ 64bit Intel only. But I'm not sure how many folks still need 32 bit. -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
Thanks Chris, From earlier in the thread the statement was made:
i.e would the same binary wheel work for both?
It should, and we will fix issues if they come up.
in reference to Windows builds against MSVC 2008. I was asking if this "binary compatibility with python.org python" also applied to mac builds of canopy. Anyway, I'll check the repo! I'd love it it we could get vpython install strategies that worked with all the major distributions. thanks for the help! -steve On Jan 10, 2014, at 4:37 PM, Chris Barker <chris.barker@noaa.gov> wrote:
Not sure what "also" is respect to, but the pyton.org builds are a good common denominator:
The Apple builds have their issues: - Apple never upgrades them - You can't re-distribute them (build stuff with Py2app) .. at least without violating copyright.
While it's appealing for people to not have to install anything, if they are installing 3rd party packages they are installing stuff, son one extra install at the start is not a big deal.
So: if you are going to support one binary -- it should be the python.org one.
It is a bit of a pain to build binaries for the Python.org builds, as they are universal and support older OS versions.
Personally, I think we should address this by:
1) having a centralized project for building varios binary dependencies that are compatible with the python.org builds -- why should multiple package distributors all have to figure out how to build, e.g. freetype correctly?
I've created a repo for this, but haven't gotten far:
https://github.com/MacPython/osxinst
let me know if you are interested in contributing.
2) Maybe it's time to put out an "official" python.org build that's simpler: perhaps 10.7+ 64bit Intel only. But I'm not sure how many folks still need 32 bit.
-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
On 9 January 2014 04:44, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Jan 8, 2014 at 1:48 AM, David Cournapeau <cournape@gmail.com> wrote:
We don't use mingw to build packages distributed within canopy (at least not anymore). We build everything with MSVC 2008, as mixing mingw/MSVC often causes trouble.
so is Canopy binary-compatible with the python.org builds?
i.e would the same binary wheel work for both?
The same should be true for Anaconda (they had a bug where they used the wrong runtime for Python 3.3 on Windows but that should have been fixed a few months ago). Cheers, Nick.
-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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Chris Barker -
David Cournapeau -
Nick Coghlan -
Steve Spicklemire