Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 5:55 AM, Nick Coghlan wrote: > > And maybe it's good to keep "new style" configuration clearly separate. > > Part of my motivation for suggesting re-using setup.cfg is the > proliferation of packaging related config sprawl in project root > directories

Re: [Distutils] moving things forward

On Thu, May 5, 2016 at 10:45 PM, Greg Ewing wrote: > Even if python is available, you might not want to run > arbitrary code just to install a package. > > If a config file can contain executable code, then it > can contain bugs. Debugging is something the developer

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote: > The "Python-with-imports" case is the status quo with setup.py, and we > already know that's a pain because you need to set up an environment > that already has the right dependencies installed to enable your > module

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 6:37 PM, Robert Collins wrote: > > Thats good. It occurs to me that scientific builds may be univerally > broken because folk want to avoid easy-install and the high cost of > double builds of things. E.g. adding bootstrap_requires will let folk

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 4:32 PM, Nathaniel Smith wrote: > > You do know that we're on our way to re-writing conda, now, don't you? > :-) > > > > I think we need to be careful of scope-creep... > > conda did not invent the idea of creating separate python environments > for

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 9:39 AM, Donald Stufft <don...@stufft.io> wrote: > On May 6, 2016, at 11:54 AM, Chris Barker <chris.bar...@noaa.gov> wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-inventing c

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 8:09 PM, Nick Coghlan wrote: > I know I'm one of the folks that has historically been dubious of the > "just use setup.cfg" idea, due to the assorted problems with the > ini-style format not extending particularly well to tree-structured > data (beyond

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

We've spent a huge amount of effort on reaching the point where pretty > much everything *can* be made pip installable. Heck, *PyQt5*, which is > my personal benchmark for a probably-totally-unpackageable package, > announced last week that they now have binary wheels on pypi for all > of

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 3:33 AM, Donald Stufft wrote: > I'd actually prefer not using JSON for something that is human > editable/writable because I think it's a pretty poor format for that case. > It > is overly restrictive in what it allows (for instance, no trailing comma >

Re: [Distutils] The mypy package

e from using it forever. And note that it's possible for someone to put up a useful web site on a free hosting service, attach it to their domain name, and then abandon it -- sure, there may be someone out there that finds that site useful years from now -- but those are the breaks. -CHB > Jim &

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 8:48 AM, David Wilson wrote: > Namespaces seem like a great idea, then these problems disappear > entirely, huh? as far as I can tell, namespaces greatly expand the pool of available names, but other than that, we've got the same problem.

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:41 AM, David Wilson wrote: > > huh? as far as I can tell, namespaces greatly expand the pool of > available > > names, but other than that, we've got the same problem. > > They seem to have worked well enough from the 1980s through to the

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:37 AM, Alexander Walters wrote: > Greatly expanding the pool of names solves the problem. > some of it, maybe, but not the problem at hand -- mypy has already put itself up as "mypy-lang", an namespace would be pretty much the same thing. if

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:30 AM, Alexander Walters wrote: > We absolutely do not. Names are first come, first serve, in perpetuity. I'm suggesting that the "in perpetuity" bit is NOT a good way to go -- packages are abandoned, and the longer this goes on, the more

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

You've made a strong case, and this is probably not where PyPi should go -- but it would hardly be a disaster: > The idea of expiring out names has been brought up recently to resolve an > issue of two packages, one popular and large; another someone's weekend > project. The issue here is not

Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

On Tue, Apr 19, 2016 at 9:45 AM, Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Instead of overtaking, > how about clearly marking packages as abandoned/maintained clearly > pointing out the mark was imposed by community action > I think that would be a good idea -- and maybe

Re: [Distutils] The mypy package

On Tue, Apr 19, 2016 at 7:59 AM, Nick Coghlan wrote: > However, as others have noted, we don't really have the resources to > administer a PyPI name dispute resolution system - when there are legal > issues, the PyPI admins can escalate matters to the PSF Board (but those >

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco wrote: > >> 1. PyYAML is a package that would be de-registered in such a scheme. > It > > > and you don't think ANYONE would be willing to take on the miniscule > amount > > of work to maintain the name? Plus there

Re: [Distutils] How to add GDAL as a dependency to a Python package

On Wed, Apr 13, 2016 at 12:02 AM, Luí­s de Sousa < luis.de.so...@protonmail.ch> wrote: > Thank you for the reply Chris. > > I just tried to install pygdal directly from PiPY on a stock Ubuntu > distribution and it fails [0], even if I supposedly have all the necessary > headers installed. >

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sat, May 7, 2016 at 11:18 AM, Brett Cannon wrote: > What fields there will be and their semantics ... > >1. Format version (so just deciding on a name -- which also includes > whether it should be top-level or in a subsection -- and initial value) > 2. The

Re: [Distutils] moving things forward

On Sat, May 7, 2016 at 6:17 AM, Greg Ewing wrote: > Do you expect that > >> projects ... should (somehow) contain simplified instructions on how to >> build the various C/Fortran extensions supplied in the bundle as >> source code? >> > > Essentially, yes. I'm not

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 May 2016 01:55, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-i

Re: [Distutils] comparison of configuration languages

On Sat, May 7, 2016 at 6:04 PM, Brett Cannon wrote: For both options I hear "pick a new format", which suggests we might as > well do it from the get-go for clear separation of the new stuff and just > bite the bullet instead of simply postponing a decision; it isn't like our >

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sun, May 8, 2016 at 5:49 AM, Nick Coghlan wrote: > The reason I think "bootstrap" is a better name at this point I *really* don't want to add to the bike-shedding of the name at this point -- I really don't care. I was just trying to see if I was misunderstanding

Re: [Distutils] comparison of configuration languages

> > "pymeta" feels very "inessentially weird" to me [1]. yeah... setup.toml ??? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Sun, May 8, 2016 at 5:31 AM, Nick Coghlan wrote: > > any python developer is going to > > run into these issues eventually... > > Aye, I know - conda was one of the systems I evaluated as a possible > general purpose tool for user level package management in Fedora and >

Re: [Distutils] comparison of configuration languages

Really? writing Yet Another Markup Language (YAML :-) ) CAN'T be the simplest, best option. > After further consideration, and pytoml's author's comment about the spec changing without a version increase, I think we might be better off rolling our own. > > I like the general simplicity, and

Re: [Distutils] If you want wheel to be successful, provide a build server.

On Wed, May 25, 2016 at 8:27 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > I think providing a self hostable build server which can be started with > one command > would be such a project. The manylinux Docker container is heading in that direction already. I suggest you consider

Re: [Distutils] Contributing money to package authors/maintainers via PyPI

On Sat, Jul 23, 2016 at 12:22 PM, Nathaniel Smith wrote: > OTOH, if we give up on that part of the idea, then it becomes much easier > :-). It'd be straightforward for PyPI to provide a "how to donate to this > project" box on each project page, that has links to whatever

Re: [Distutils] bulk upload

On Mon, Jul 25, 2016 at 8:55 AM, Robin Becker wrote: > In our private readonly pypi we have 93 releases. I don't think that > burden should fall on pypi. However, it's not clear to me if I should push > micro releases to pypi and then remove them when another release is

Re: [Distutils] license for setuptools

Sorry for the noise -- I was way too late to this game -- blib in my email, I guess. -CHB On Fri, Aug 12, 2016 at 10:01 AM, Chris Barker <chris.bar...@noaa.gov> wrote: > it looks like the OP is looking for the license to setuptools, not > matplotlib. > > (MPL's licence f

Re: [Distutils] pip3 subversion user

On Thu, Aug 4, 2016 at 11:36 AM, Weatherby,Gerard wrote: > Apologies in advance if this is the wrong list for the question; if so, > a pointer to the correct one would be appreciated. > > I'm trying to user the subversion option of pip3 to install a package; I > can use >

[Distutils] What role to eggs still play?

Hi all, starting a new thread, but this is related to the setuptols-_lite discussion, and the legacy formats discussion. In another thread Donald had a footnote: [1] We can tackle egg at a later point, when setuptools either has support > for Wheels > or is less needed. So I'm wondering

Re: [Distutils] Future of setuptools and buildout

On Thu, Aug 18, 2016 at 10:17 PM, Wes Turner wrote: > setuptools does all of these, yes? but think of these in terms of when >> they come into play: >> >> build time: >>- building a package >> > > - building c extensions > - building NumPy (fortran,) > exactly! which

Re: [Distutils] Future of setuptools and buildout

On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth wrote: > And a while back I argued against setuptools-lite, because I thought it > would not solve the poor extensibility problem that stems from its basic > distutils derived design... which includes all the classes and subclasses

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

On Tue, Aug 16, 2016 at 9:10 AM, Donald Stufft wrote: > > Ah, I knew I was forgetting something. I think we should hold off on > preventing egg uploads until setuptools can download and install wheels. > Aren't we trying to get to the point where setuptools doesn't download and

Re: [Distutils] Future of setuptools and buildout

> > Which brings us to a question that I'm meaning to ask for a while. > > It looks like we're close to removing all mentions of setuptools in pip. > When this happens, it looks like pressure is going to start to mount on > setuptools to drop the ability to install packages and limit itself on >

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

On Tue, Aug 16, 2016 at 8:51 AM, Brett Cannon wrote: > One thing to remember is that Windows can't read tar files natively while > it can for zip files. Now you can easily download tools on Windows to read > tar files and thanks to Bash on Windows you even have it included once

Re: [Distutils] When can we kill Python 2.6 support?

> Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6. And a lot of those may be CI systems for packages that still support 2.6 deprecate away! -CHB On Sat, Sep 3, 2016 at 1:36 PM,

Re: [Distutils] Module Installation Issues

> > I think Ryan may have typed that command at a Python prompt rather than >> a system command prompt. Unfortunately the distinction often isn't clear >> in examples, because the experienced developers writing the instructions >> are used to guessing which commands are Python and which are system

Re: [Distutils] Current Python packaging status (from my point of view)

Final note after a long thread: Just like Nick pointed out in his original post (if I read it right) , the pip vs the conda approach comes down to this: Do you want to a system to manage the whole stack? or do you want a system to manage Python packages? Personally, I think that no matter how

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Fri, Nov 4, 2016 at 11:29 PM, Nick Coghlan wrote: > If I understand correctly, conda-forge works on the same basic > principle - reviewing the publishers before granting them publication > access, rather than defending against arbitrarily malicious code at > build time. >

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver wrote: > Questions: > 1. Editable installs. The PEP currenly specifies a hook to do an > editable install (like 'pip install -e' or 'setup.py develop') into a > given prefix. I don't think that specifying a prefix is

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > > > Please, please, let's figure SOMETHING our here - editable installs (or > > "develop" inst

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016 at 3:10 PM, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? exactly. The fact that setuptools over-uses (abuses?) pth files doesn't

Re: [Distutils] PEP 517: Build system API

On Mon, Nov 28, 2016 at 10:01 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 November 2016 at 17:53, Chris Barker <chris.bar...@noaa.gov> wrote: > >> Why not just have a single pth file, maintained by the build > >> tool, for all editable installs? >

Re: [Distutils] Current Python packaging status (from my point of view)

On Tue, Nov 1, 2016 at 5:19 AM, Nick Coghlan wrote: > It isn't that simple, as what you really want to automate is the > *release process*, where you upload an sdist, and the wheels *just > happen* for: > > - the Python versions you want to support (e.g 2.7, 3.4, 3.5) > - the

Re: [Distutils] Current Python packaging status (from my point of view)

On Tue, Nov 1, 2016 at 2:50 AM, Nick Coghlan wrote: > > I wrote some lines, but I deleted my thoughts about the topic > "Automating wheel creation", since > > I am a afraid it could raise bad mood in this list again. That's not my > goal. > > I currently see 3 main ways that

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 9:49 AM, Nick Coghlan wrote: > No, as the post was about the fundamental and irreconcilable > differences in capabilities, not the incidental ones that can be > solved if folks choose (or are paid) to put in the necessary design > and development time.

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 9:57 AM, Donald Stufft wrote: > > On Nov 2, 2016, at 12:49 PM, Nick Coghlan wrote: > > > > I also mean 2.6 vs 2.7 vs 3.4 vs 3.5 vs 3.6, etc > Of course, but that has nothing to do with the package management system... > There are

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 11:31 AM, Donald Stufft wrote: > Sure. Do whatever you want, I don’t think anyone here thinks you > absolutely must use pip. :) [1] > indeed -- and IIUC, part of the thrust of Nick's post was that different package managers serve different use-cases --

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 2:34 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 2 November 2016 at 23:08, Chris Barker <chris.bar...@noaa.gov> wrote: > > After all, you can use pip from within a conda environment just fine :-) > > In my experience (some time ago) doing so

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:39 AM, Nick Coghlan wrote: > I don't think there's much chance of any of this ever working on > Windows - conda will rule there, and rightly so. Mac OS X seems likely > to go the same way, although there's an outside chance brew may pick > up some of

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote: > Even on the "hard" cases like Windows, it may be possible to define a > standard approach that goes something along the lines of defining a > standard location that (somehow) gets added to the load path, and > interested

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 10:56 AM, Matthew Brett wrote: > But - it would be a huge help if the PSF could help with funding to > get mingw-w64 working. This is the crucial blocker for progress on > binary wheels on Windows. for what it's worth, this is a blocker for

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 5:02 PM, Matthew Brett wrote: > Anaconda has an overwhelming advantage on Windows, in that Continuum > can bear the licensing liabilities enforced by the Intel Fortran > compiler, and we can not. Technically, that's an advantage that a commercial

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote: > It would buy *me* flexibility to use python.org build of Python, or my > own builds. And not to have to wait for conda to release a build of a > new version. you are perfectly free to make your own conda package of python

Re: [Distutils] Current Python packaging status (from my point of view)

Hey Matthew, > [1] There seems to be some animosity among pip supporters and conda > > supports, or at least a perception that there is. > > I don't know whether there is animosity, but there is certainly > tension. Speaking personally, I care a lot about having the option to > prefer pip.

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 7:32 AM, Nick Coghlan wrote: > > He mentioned that conda allows you to > > manage the python run-time itself, which is in deed a nice feature, but > > getting a python run-time as never been the hard part (maybe on Linux if > you > > want a different

Re: [Distutils] Maintaining a curated set of Python packages

As pointed out by others, there are external groups doing "curating". conda-forge is one such project, so I'll comment from that perspective: It's difficult because the definition of compatibility is highly dependent on > > the consumer's environment. For example, C extension compatibility will

Re: [Distutils] Maintaining a curated set of Python packages

On Fri, Dec 16, 2016 at 5:51 AM, Daniel Holth wrote: > One possibility to consider is that virtualenv itself is a bad idea. Why > should the Python interpreter executable, rather than the program being > run, determine the set of packages that is available for import? > well,

Re: [Distutils] Maintaining a curated set of Python packages

On Thu, Dec 15, 2016 at 8:29 PM, Glyph Lefkowitz wrote: > At the beginning of your story you mentioned the GUI client - *that* is > the missing piece ;). I've been saying for years that we need a Python.app > that lets you easily bootstrap all this stuff: walk you

Re: [Distutils] Which commercial vendor?

On Wed, Apr 5, 2017 at 6:41 PM, Nick Coghlan wrote: > PayPal Engineering put together a decent write-up of their path > towards adopting that model last year: > https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/ Thanks for that link. We're a much

Re: [Distutils] Which commercial vendor?

On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner wrote: > Chances are, there will be a package or two that you rely on that is not >> in conda defaults (maintained by Continuum) or currently in conda-forge. So >> you can pip-install those few -- but what if they aren't on PyPi

Re: [Distutils] new PyPI: a rant from a package maintainer

one point: I probably should have named it something other than /legacy/, > yes, it should have -- names matter! and having a "legacy" in teh name when there is not "modern" or "current", or, indeed, anything else is very confusing. pypi.org, might as well get it all done at once. It might

Re: [Distutils] new PyPI: a rant from a package maintainer

On Fri, Aug 4, 2017 at 5:42 PM, Lucas Boppre Niehues wrote: > > The long description was originally Markdown, and converted to RST by > pandoc. I would 100% understand if this conversion triggered some bug. > It's a good idea to run docutils on it yourself -- but in any

Re: [Distutils] PEP 517 again

> conda-build doesn't produce or consume wheels. It works by creating a > clean > > conda environment and running a shell script to install the python > package > > into that environment To be really clear -- conda build doesn't directly use ANY build/install system. All files produced by the

Re: [Distutils] PEP 517 again

On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan wrote: > >> Do the Linux distros use pip to build their packages? > > > > Not that I am aware of. > > Fedora's build macros for Python projects currently rely on running > setup.py directly, but we've been considering switching to

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft wrote: > Donald, what do you think? IIRC, you were most keen on going > sdist->wheel where possible, and I don't think you've commented on > Paul's suggestion yet (apologies if I've overlooked a response). > > > I still think it

Re: [Distutils] PEP 517 again

On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore wrote: > > Suppose you > > have a frontend like pip that when given a source directory and asked > > to build a wheel, wants to implement that as: > > - build sdist > > - unpack sdist > > - build wheel from unpacked sdist > >

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

I've thought for ages that we could transition to a more sane system by convention: "your setup.py, after being imported, will have a "setup_params" attribute that is a dict that can be passed to setup()." So tools that want metadata, etc. without actually running an install could do; import

Re: [Distutils] PEP 517 again

t->wheel protects the user against the known-to-be-an-issue bug > that the backend doesn't ensure wheel equivalence. pip can not protect the user from a poorly written back-end. And it shouldn't try. * Chris Barker has pointed out that backends have no reason to support > sdists now. &

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 12:50 PM, Paul Moore wrote: > Me too. At the moment, I only expect two backends of any substance - > your flit backend and xoviat's setuptools one. But I only know of one > frontend, namely pip - and talk of projects like tox or twine acting > as

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan wrote: since it > doesn't reliably distinguish between "this cached wheel was downloaded > from a repository" and "this wheel was generated locally with a > particular version of Python". It shouldn't have to. sigh. > PEP 517

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote: > > As to using pip to build wheels -- there is good reason to do that > > now, but in s post PEP 517 world, one would call the build system > > directly to build a wheel-- after all, all pip should be doing is > > calling

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 9:04 AM, Donald Stufft wrote: > I'm a bit confused -- are we talking about the backwards compatible > path to the future -- or the end-game? > > > Pip purposely overrides what setuptools tags the wheel with in order to > make it extremely specific to the

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith wrote: > > Surely the build system should know how to correctly name the wheel it > builds. > > It's probably worth mentioning the specific problem that motivated pip > to start doing this. > > It used to be standard, and is still

Re: [Distutils] How to eliminate on part of a package?

frankly, I'd give up n find_packages -- it's not that magic, it's just a convenience function so you don't need to hand-specify them. But in this case, you're doing something weird, so I"d just be explicit. Though what I'd probably really do is make the client and server completely separate

[Distutils] Binary Wheels and universal builds on OS-X

HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be universal -- what this means is

Re: [Distutils] Binary Wheels and universal builds on OS-X

-- use it If a non-universal binary is found that matches the currently running python -- then what? install it with a warning? raise an exception? -Chris On May 31, 2013 6:30 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: HI Folks, A few of us over on the pythonmac

Re: [Distutils] Binary Wheels and universal builds on OS-X

And Ned, Thanks for your offer to write something up -- looking forward to it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317

Re: [Distutils] Binary Wheels and universal builds on OS-X

Darn! this slipped off the list -- I hate it when lists aren't set with the reply-to address as the list... On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dho...@gmail.com wrote: ppc is not completely dead? I have one under my desk, though truth be told, I haven't turned it on in a good while...

[Distutils] Fwd: Binary Wheels and universal builds on OS-X

Folks, Accidentally let this slip off the list... -Chris -- Forwarded message -- From: Chris Barker - NOAA Federal chris.bar...@noaa.gov Date: Mon, Jun 3, 2013 at 1:33 PM Subject: Re: [Distutils] Binary Wheels and universal builds on OS-X To: Daniel Holth dho...@gmail.com

Re: [Distutils] Binary Wheels and universal builds on OS-X

On Tue, Jun 4, 2013 at 1:23 AM, Ronald Oussoren ronaldousso...@mac.com wrote: This isn't really a problem, distutils uses labels for the set of supported architectures as the architecture label in binary distributions (e.g. pyobjc_core-2.5-py3.4-macosx-10.8-intel.egg for an egg that supports

Re: [Distutils] Binary Wheels and universal builds on OS-X

On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth dho...@gmail.com wrote: That would make sense. Can you come up with code to detect that a newly compiled extension is universal, and that a Python is? It looks like distutils.util.get_platform() now does the right thing for knowing what the

Re: [Distutils] Binary Wheels and universal builds on OS-X

On Tue, Jun 4, 2013 at 10:06 AM, Ronald Oussoren ronaldousso...@mac.com wrote: This is not ideal, but works good enough for now. In the long run this should likely be replaced by the compressed tags sets from PEP 425 (at the cost of a much longer file names). I think now may be the long

Re: [Distutils] Binary Wheels and universal builds on OS-X

On Tue, Jun 4, 2013 at 9:55 AM, Ronald Oussoren ronaldousso...@mac.com wrote: $ otool -L python python (architecture ppc): /Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0) /usr/lib/libmx.A.dylib (compatibility version

Re: [Distutils] wxPython and wx

On Fri, Jun 7, 2013 at 12:56 AM, Yuval Greenfield ubershme...@gmail.com wrote: I realize we don't want to start squat-wars. But pypi's wx is a 5 liner that absolutely no person would ever want installed. At the least, pip should warn me when I install wx that it's probably not what I'm looking

Re: [Distutils] $MACOSX_DEPLOYMENT_TARGET mismatch

This is really a build question, rather than a distributuion question -- Id try the pythonmac list: http://mail.python.org/mailman/listinfo/pythonmac-sig I recall that readline is a bit of a pain on the Mac, but don't recall the solution (nor am I running 10.8 yet). Good luck, -Chris On Wed,

Re: [Distutils] $MACOSX_DEPLOYMENT_TARGET mismatch

On Wed, Jul 3, 2013 at 12:12 PM, Alan alanwil...@gmail.com wrote: Well, I found out that if before compiling my python I set export MACOSX_DEPLOYMENT_TARGET=10.3 and then do all the rest, then I get easy_install to work. cool - well done. So, somehow my python (or setuptools) need to build

Re: [Distutils] Expectations on how pip needs to change for Python 3.4

On Sat, Jul 13, 2013 at 12:59 PM, Paul Moore p.f.mo...@gmail.com wrote: 2. This sounds like something that needs fixed on Windows. Even if you say ``-m`` for pip then things are still broken by default for any other package on PyPI that installs a script. So this feels like something wrong with

Re: [Distutils] Expectations on how pip needs to change for Python 3.4

On Mon, Jul 15, 2013 at 10:11 AM, Paul Moore p.f.mo...@gmail.com wrote: of Steve Dower, I guess :-)) Powershell is a *great* step up from cmd, could we use a powershell script to launch python scripts? Maybe it wouldn't be any easier to update than an exe, but it might be more accessible. Of

Re: [Distutils] Expectations on how pip needs to change for Python 3.4

On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft don...@stufft.io wrote: There is something like 200 total bdist_msi on PyPI and 5k bdist_wininst. To put numbers into perspective, there are ~180k total files uploaded to PyPI. I don't hink this means that the installers aren't widely used, I

Re: [Distutils] How to handle launcher script importability?

Just $0.02 from a user... I'm primarily an OS-X user these days, but have to do Windows once in a while, and help others do Windows (including as an intro to Python instructor) Once I discovered setuptools develop mode, I never looked bak -- it is simpl;y THE way to develop code, particularly if

Re: [Distutils] How to handle launcher script importability?

On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore p.f.mo...@gmail.com wrote: 3) I'd rather not have to mess with PATHEXT, and I particularly don't want to have to tell my students to do it -- environment variables are a pain, and somehow PATHEXT has been fragile for me (and I don't use Cygwin)

Re: [Distutils] distutils.util.get_platform() - Linux vs Windows

On Tue, Aug 20, 2013 at 9:00 AM, samuel.feren...@barclays.com wrote: That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() derives the value from uname for OS X, similar to Linux. (osname, host, release, version, machine) = os.uname() ... elif osname[:6]

Re: [Distutils] distutils.util.get_platform() - Linux vs Windows

On Mon, Aug 19, 2013 at 11:15 PM, samuel.feren...@barclays.com wrote: What does your 'uname -m' return? x86_64 Is it possible you're really running a 32-bit Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195] nope -- I am quite deliberately running a 32 bit Python on my 64

Re: [Distutils] What does it mean for Python to bundle pip?

On Thu, Aug 22, 2013 at 6:52 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I'm pretty sure the current Windows installer just doesn't bother with BLAS/LAPACK libraries. Maybe it will become possible to expose them via a separate wheel-distributed PyPI name one day. Well, the rule of

Re: [Distutils] What does it mean for Python to bundle pip?

On Thu, Aug 22, 2013 at 9:37 AM, Paul Moore p.f.mo...@gmail.com wrote: That is essentially possible now. 1. Go to Christoph Gohlke's website and download his bdist_wininst installers for numpy and scipy. Exactly. And when all this settles down, hopefully Christoph, and others, will put

Re: [Distutils] What does it mean for Python to bundle pip?

On Thu, Aug 22, 2013 at 3:52 PM, Paul Moore p.f.mo...@gmail.com wrote: On 22 August 2013 23:08, Chris Barker - NOAA Federal chris.bar...@noaa.gov My impression is that the architecture and fat binary stuff on OSX is the bit that may bite you. exactly. I know little or nothing about OSX

<    1   2   3   4   >