[Distutils] Re: Archive this list & redirect conversation elsewhere?

On Tue, 4 Aug 2020 at 23:03, Brett Cannon wrote: > On Thu, Jul 30, 2020 at 8:41 AM Wes Turner wrote: >> >> I confess that I don't even know how to subscribe to all threads of a >> discourse. >> >> - [ ] How to subscribe to all threads of discourse > > Go to the category you care about, e.g. >

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

On 10 February 2016 at 12:21, M.-A. Lemburg wrote: >> So "easy to achieve" still needs someone to take the time to deal with >> these sorts of issue. It's the usual process of the people willing to >> put in the effort get to choose the direction (which is also why I >> just

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 30 January 2016 at 08:58, Nick Coghlan wrote: > > I applied both this iteration and the previous one to the PEPs repo in > order to review it, so modulo caching issues, this latest draft is > live now. > > I also think this version covers everything we need it to cover, so

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

On 28 January 2016 at 07:46, Nathaniel Smith wrote: > > On further thought, I realized that it actually has to be in the > standard library directory / namespace, and can't live in > site-packages: for the correct semantics it needs to be inherited by > virtualenvs; if it isn't

Re: [Distutils] Trouble using setuptools to build separate c++ extension

On 20 December 2015 at 03:15, Thomas Nyberg wrote: > Hello I'm having trouble understanding the right way to build a c++ module > using setuptools. I've been reading the docs, but I'm confused where I > should be putting my build options. Everything builds fine on its own. I

Re: [Distutils] Installing packages using pip

On 14 Nov 2015 11:12, "Paul Moore" wrote: > > On 13 November 2015 at 23:38, Nathaniel Smith wrote: > > But details of R's execution model make this easier to do. > > Indeed. I don't know how R works, but Python's module caching > behaviour would mean this

Re: [Distutils] The future of invoking pip

On 11 November 2015 at 06:35, Nick Coghlan wrote: > > Longer term, it may even make sense to take the "python" command on > *nix systems in that direction, or, at the very least, make "py" a > cross-platform invocation technique: >

Re: [Distutils] The future of invoking pip

On 9 November 2015 at 10:44, Wolfgang Maier wrote: > > Something I miss in all the discussions taking place here is the fact that > python -m pip is the officially documented way of invoking pip at >

Re: [Distutils] warning about potential problem for wheels

On 14 Oct 2015 19:00, "Chris Barker" wrote: > > On Wed, Oct 14, 2015 at 9:54 AM, Antoine Pitrou wrote: >> >> > IS that the case: >> > """ >> > Note that my recently retired computer was 64 bit and had SSE but didn't >> > have SSE2 (I'm fairly sure -

Re: [Distutils] warning about potential problem for wheels

On Sun, 11 Oct 2015 15:31 Donald Stufft wrote: Will something built against 3.5.0 with SSE work on 3.5.1 without SSE? What about the inverse? It should be fine either way as long as the CPU can handle the particular instructions used. X86 is backward compatible like that so

Re: [Distutils] warning about potential problem for wheels

On Sun, 11 Oct 2015 17:44 Antoine Pitrou wrote: On Sun, 11 Oct 2015 08:07:30 -0700 Steve Dower wrote: > > This does only affect 32-bit builds, so now I'm thinking about the > possibility of treating those as highly compatible while the 64-bit > ones

Re: [Distutils] warning about potential problem for wheels

On Sat, 10 Oct 2015 20:53 Laura Creighton wrote: (note, I currently don't have mail delivery on for distutils. I could change this, but right now I don't think I have a lot to contribute. This is just a warning). If you have old windows hardware, which does not support SSE2,

Re: [Distutils] warning about potential problem for wheels

On Sat, 10 Oct 2015 23:37 Laura Creighton <l...@openend.se> wrote: In a message of Sat, 10 Oct 2015 21:52:58 -, Oscar Benjamin writes: >Really this is just a case of an unsupported platform. It's unfortunate >that CPython doesn't properly support this hardware but I think it's

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, 9 Oct 2015 19:01 Carl Meyer wrote: On 10/09/2015 11:18 AM, Paul Moore wrote: > On 9 October 2015 at 18:04, Chris Barker wrote: >> 1) what in the world is a "source wheel"? And how is it different than an >> sdist (other than maybe in a different

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, 9 Oct 2015 19:35 Carl Meyer <c...@oddbird.net> wrote: On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 7 October 2015 at 22:41, Paul Moore wrote: > On 7 October 2015 at 22:28, Nathaniel Smith wrote: >> Maybe I have misunderstood: does it actually help pip at all to have >> static access to name and version, but not to anything else? I've been >> assuming

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 13:05, Ionel Cristian Mărieș <cont...@ionelmc.ro> wrote: > On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin <oscar.j.benja...@gmail.com> > wrote: >> >> I think this satisfies all of the requirements for static metadata and >> one-to-one corres

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 12:46, Paul Moore <p.f.mo...@gmail.com> wrote: > On 8 October 2015 at 11:18, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: >> >> A concrete example would be whether or not the numpy source wheel >> depends on pyopenblas. Depending on how n

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 8 October 2015 at 14:34, Ionel Cristian Mărieș wrote: > > On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote: >> >> One of the features in the original PEP was the ability to produce >> multiple >> different Wheels from the same source release much like

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, 7 Oct 2015 19:42 Donald Stufft <don...@stufft.io> wrote: On October 7, 2015 at 2:31:03 PM, Oscar Benjamin (oscar.j.benja...@gmail.com) wrote: > > > Your idea of an sdist as something that has fully static build/runtime > dependency metadata and a one to one correspo

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Wed, 7 Oct 2015 18:51 Donald Stufft wrote: On October 7, 2015 at 1:27:31 PM, Nathaniel Smith (n...@pobox.com) wrote: > On Mon, Oct 5, 2015 at 6:51 AM, Donald Stufft wrote: > [...] > > I also don't think it will be confusing. They'll associate the VCS thing (a source

Re: [Distutils] (no subject)

: PyMODINIT_FUNC initspam(void) { (void) Py_InitModule(spam, SpamMethods); } I tried doing that and it crashed Python when I imported _spam - Original Message - From: Oscar Benjamin oscar.j.benja...@gmail.com To: garyr ga...@fidalgo.net; distutils-sig@python.org Sent: Tuesday, August 18

Re: [Distutils] (no subject)

Should the function be called init_spam rather than initspam? On Tue, 18 Aug 2015 19:19 garyr ga...@fidalgo.net wrote: I posted this on comp.lang.python but received no replies. I tried building the spammodule.c example described in the documentation section Extending Python with C or C++. As

Re: [Distutils] Working toward Linux wheel support

On Fri, 24 Jul 2015 at 19:53 Chris Barker chris.bar...@noaa.gov wrote: On Tue, Jul 21, 2015 at 9:38 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I think it would be great to just package these up as wheels and put them on PyPI. that's the point -- there is no way

Re: [Distutils] Working toward Linux wheel support

On Fri, 17 Jul 2015 at 16:37 Chris Barker chris.bar...@noaa.gov wrote: TL;DR -- pip+wheel needs to address the non-python dependency issue before it can be a full solution for Linux (or anything else, really) snip - Packages with semi-standard dependencies: can we expect ANY Linux distro

Re: [Distutils] Making pip and PyPI work with conda packages

On 19 May 2015 at 10:55, Paul Moore p.f.mo...@gmail.com wrote: But python, setuptools, pip, wheel, etc. don't have a way to handle that shared lib as a dependency -- no standard way where to put it, no way to package it as a wheel, etc. So the way to deal with this with wheels is to

Re: [Distutils] Deferring metadata hooks

On 2 March 2014 07:25, Nick Coghlan ncogh...@gmail.com wrote: I've just posted updated versions of PEP 426 and 459 that defer the metadata hooks feature. The design and behaviour of that extension is still way too speculative for me to approve in its current form, but I also don't want to

Re: [Distutils] Deferring metadata hooks

On 2 March 2014 21:05, Nick Coghlan ncogh...@gmail.com wrote: I think this approach may also encourage a design where projects do something sensible *by default* (e.g. NumPy defaulting to SSE2) and then use the (not yet defined) post-installation hooks to potentially *change away* from

Re: [Distutils] Cross-platform way to get default directory for binary files like console scripts?

On 21 February 2014 13:24, Paul Moore p.f.mo...@gmail.com wrote: Is there cross-platform way to get default directory for binary files (console scripts for instance) the same way one can use sys.executable to get path to the Python's interpreter in cross-platform way?

Re: [Distutils] pip on windows experience

On 24 January 2014 22:40, Paul Moore p.f.mo...@gmail.com wrote: On 24 January 2014 22:21, Chris Barker chris.bar...@noaa.gov wrote: well, numpy _should_ build out of the box with nothing special if you are set up to build regular extensions. I understand that a lto f Windows users are not set

Re: [Distutils] pip on windows experience

On 24 January 2014 10:18, Nick Coghlan ncogh...@gmail.com wrote: On 24 Jan 2014 19:41, Paul Moore p.f.mo...@gmail.com wrote: On 24 January 2014 00:17, Oscar Benjamin oscar.j.benja...@gmail.com wrote: You need to bear in mind that people currently have a variety of ways to install numpy

Re: [Distutils] pip on windows experience

On Thu, Jan 23, 2014 at 12:16:02PM +, Paul Moore wrote: The official numpy installer uses some complex magic to select the right binaries based on your CPU, and this means that the official numpy superpack wininst files don't convert (at least I don't think they do, it's a while since I

Re: [Distutils] pip on windows experience

On 23 January 2014 23:58, Nick Coghlan ncogh...@gmail.com wrote: I really think that's our best near term workaround - still room for improvement, but pip install numpy assumes SSE2 is a much better situation than pip install numpy doesn't work on Windows. Is it? Do you have any idea what

Re: [Distutils] Handling the binary dependency management problem

On 6 December 2013 13:06, David Cournapeau courn...@gmail.com wrote: As Ralf, I think it is overkill. The problem of SSE vs non SSE is because of one library, ATLAS, which as IMO the design flaw of being arch specific. I always hoped we could get away from this when I built those special

Re: [Distutils] Binary dependency management, round 2 :)

On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote: On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote: == Regarding conda == In terms of providing an answer to the question Where does conda fit in the scheme of packaging tools?, my conclusion from the thread is

Re: [Distutils] Handling the binary dependency management problem

On 4 December 2013 20:56, Ralf Gommers ralf.gomm...@gmail.com wrote: On Wed, Dec 4, 2013 at 5:05 PM, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: So a lowest common denominator wheel would be very, very, useful. As for what that would be: the superpack is great, but it's been

Re: [Distutils] Binary dependency management, round 2 :)

On 5 December 2013 00:06, Marcus Smith qwc...@gmail.com wrote: but Anoconda does some a nifty thing: it make s conda package that holds the shared lib, then other packages that depend on it depend on that package, so it will both get auto--installed But I don't see why you couldn't do that

Re: [Distutils] Handling the binary dependency management problem

On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote: On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft don...@stufft.io wrote: I’d love to get Wheels to the point they are more suitable then they are for SciPy stuff, That would indeed be a good step forward. I'm interested to try

Re: [Distutils] Handling the binary dependency management problem

On 4 December 2013 12:10, Nick Coghlan ncogh...@gmail.com wrote: On 4 December 2013 20:41, Oscar Benjamin oscar.j.benja...@gmail.com wrote: Another possibility is that the pip/wheel/PyPI/metadata system can be changed to allow a variant field for wheels/sdists. This was also suggested

Re: [Distutils] Handling the binary dependency management problem

On 3 December 2013 10:19, Nick Coghlan ncogh...@gmail.com wrote: Or how about a scientist that wants wxPython (to use Chris' example)? Apparently the conda repo doesn't include wxPython, so do they need to learn how to install pip into a conda environment? (Note that there's no wxPython

Re: [Distutils] Handling the binary dependency management problem

On 1 December 2013 04:15, Nick Coghlan ncogh...@gmail.com wrote: conda has its own binary distribution format, using hash based dependencies. It's this mechanism which allows it to provide reliable cross platform binary dependency management, but it's also the same mechanism that prevents low

Re: [Distutils] Handling the binary dependency management problem

On 3 December 2013 13:53, Nick Coghlan ncogh...@gmail.com wrote: On 3 December 2013 22:49, Oscar Benjamin oscar.j.benja...@gmail.com wrote: Hmm, I likely wouldn't build it into the core requirement system (that all operates at the distribution level), but the latest metadata updates split out

Re: [Distutils] Handling the binary dependency management problem

On 3 December 2013 22:18, Chris Barker chris.bar...@noaa.gov wrote: On Tue, Dec 3, 2013 at 12:48 AM, Nick Coghlan ncogh...@gmail.com wrote: Because it already works for the scientific stack, and if we don't provide any explicit messaging around where conda fits into the distribution picture,

Re: [Distutils] Handling the binary dependency management problem

On 3 December 2013 21:13, Donald Stufft don...@stufft.io wrote: I think Wheels are the way forward for Python dependencies. Perhaps not for things like fortran. I hope that the scientific community can start publishing wheels at least in addition too. The Fortran issue is not that complicated.

Re: [Distutils] Handling the binary dependency management problem

On 2 December 2013 09:19, Paul Moore p.f.mo...@gmail.com wrote: On 2 December 2013 07:31, Nick Coghlan ncogh...@gmail.com wrote: The only problem I want to take off the table is the one where multiple wheel files try to share a dynamically linked external binary dependency. OK. Thanks for

Re: [Distutils] Handling the binary dependency management problem

On 2 December 2013 13:54, Paul Moore p.f.mo...@gmail.com wrote: If the named projects provided Windows binaries, then there would be no issue with Christoph's stuff. But AFAIK, there is no place I can get binary builds of matplotlib *except* from Christoph. And lxml provides limited sets of

Re: [Distutils] Handling the binary dependency management problem

On Dec 1, 2013 1:10 PM, Paul Moore p.f.mo...@gmail.com wrote: On 1 December 2013 04:15, Nick Coghlan ncogh...@gmail.com wrote: 2. For cross-platform handling of external binary dependencies, we recommend boostrapping the open source conda toolchain, and using that to install pre-built

Re: [Distutils] AttributeError: 'tuple' object has no attribute 'split'

On Oct 31, 2013 4:09 PM, Dominique Orban dominique.or...@gmail.com wrote: On 25 October, 2013 at 2:06:34 PM, Dominique Orban ( dominique.or...@gmail.com) wrote: On 25 October, 2013 at 1:56:26 PM, Oscar Benjamin ( oscar.j.benja...@gmail.com) wrote: On Oct 25, 2013 3:52 PM, Dominique

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

On Oct 31, 2013 8:50 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2013 02:24 PM, Donald Stufft wrote: To be honest the same problems likely exists on Windows, it?s just less likely and the benefits of prebuilt binaries greater. For

Re: [Distutils] AttributeError: 'tuple' object has no attribute 'split'

On 24 October 2013 21:04, Dominique Orban dominique.or...@gmail.com wrote: I hope this is the right place to ask for help. I'm not finding much comfort in the PyPi documentation or in Google searches. I uploaded my package `pykrylov` with `python setup.py sdist upload`. Installing it locally

Re: [Distutils] AttributeError: 'tuple' object has no attribute 'split'

On Oct 25, 2013 3:52 PM, Dominique Orban dominique.or...@gmail.com wrote: On 25 October, 2013 at 9:31:16 AM, Oscar Benjamin ( oscar.j.benja...@gmail.com) wrote: On 24 October 2013 21:04, Dominique Orban wrote: I hope this is the right place to ask for help. I'm not finding much comfort

Re: [Distutils] post install hook

On 21 October 2013 11:38, Thomas Güttler h...@tbz-pariv.de wrote: Hi, I can live without a post-install hook. But I think the documentation of setuptools should contain information about this. https://bitbucket.org/pypa/setuptools/issue/92/docs-post-install-hook That seems reasonable to

Re: [Distutils] Deprecate and Block requires/provides

On 17 October 2013 16:53, Donald Stufft don...@stufft.io wrote: On Oct 17, 2013, at 11:49 AM, Michael Foord fuzzy...@gmail.com wrote: Package upload certainly worked, and that is what is going to be broken. So would you be ok with deprecating and removing to equal this metadata silently

Re: [Distutils] PEP 453 quirk: pyvenv --no-download with an upgraded system pip

On 18 September 2013 15:26, Nick Coghlan ncogh...@gmail.com wrote: In creating the next draft of PEP 453, I noticed an odd quirk of the proposed pyvenv --no-download option: it bootstraps the version of pip *that was provided with Python*, rather than the version currently installed in the

Re: [Distutils] PEP 453 Round 2 - Explicit bootstrapping of pip in Python installations

On 15 September 2013 16:33, Donald Stufft don...@stufft.io wrote: So there've been a number of updates to PEP453, so i'm posting it here again for more discussion: Explicit Bootstrapping == An additional module called ``getpip`` will be added to the standard library

Re: [Distutils] Comments on PEP 426

On 8 September 2013 12:07, Paul Moore p.f.mo...@gmail.com wrote: On 7 September 2013 23:36, Carl Meyer c...@oddbird.net wrote: The *other* problem is that a custom implementation of an egg-info command is pretty much certain to be incompatible with pip injecting setuptools. And that's the big

Re: [Distutils] Comments on PEP 426

On 4 September 2013 19:16, Éric Araujo mer...@netwok.org wrote: Le 30/08/2013 03:23, Paul Moore a écrit : On 30 August 2013 00:08, Nick Coghlan ncogh...@gmail.com wrote: We also need to officially bless pip's trick of forcing the use of setuptools for distutils based setup.py files. Do we?

Re: [Distutils] Comments on PEP 426

On 5 September 2013 13:34, Daniel Holth dho...@gmail.com wrote: On Thu, Sep 5, 2013 at 5:36 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: --single-version-externally-managed just means install everything into a flat site-packages rather than installing them into their own (egg

Re: [Distutils] Comments on PEP 426

On 4 September 2013 08:51, M.-A. Lemburg m...@egenix.com wrote: On 04.09.2013 09:27, Paul Moore wrote: On 4 September 2013 08:13, M.-A. Lemburg m...@egenix.com wrote: I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for

Re: [Distutils] Comments on PEP 426

On 4 September 2013 11:30, Donald Stufft don...@stufft.io wrote: On Sep 4, 2013, at 6:21 AM, M.-A. Lemburg m...@egenix.com wrote: I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into

Re: [Distutils] Comments on PEP 426

On 4 September 2013 12:20, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 12:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote: Also would this be sufficient to decouple pip and setuptools (a reasonable goal in itself)? Or does pip depend on setuptools in more ways than

Re: [Distutils] Comments on PEP 426

On 4 September 2013 13:51, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 12:58, Nick Coghlan ncogh...@gmail.com wrote: However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant

Re: [Distutils] Comments on PEP 426

On 31 August 2013 12:03, Antoine Pitrou solip...@pitrou.net wrote: Donald Stufft donald at stufft.io writes: The sticking point is that you don't *have* to install something third-party to get yourself working on some packaging. Being able to benefit from additional features *if* you

Re: [Distutils] Comments on PEP 426

On 31 August 2013 14:24, Antoine Pitrou solip...@pitrou.net wrote: Oscar Benjamin oscar.j.benjamin at gmail.com writes: It will always be possible to ship a setup.py script that can build/install from an sdist or VCS checkout. The issue is about how to produce an sdist with a setup.py

Re: [Distutils] Comments on PEP 426

On 31 August 2013 16:03, Antoine Pitrou solip...@pitrou.net wrote: Oscar Benjamin oscar.j.benjamin at gmail.com writes: I tend to disagree. Such bugs are not fixed, not because they shouldn't / can't be fixed, but because distutils isn't really competently maintained (or not maintained

Re: [Distutils] Comments on PEP 426

On 31 August 2013 16:18, Nick Coghlan ncogh...@gmail.com wrote: Even the current bento issue mentioned in this thread appears to be Windows specific. I don't think you read what I wrote properly. There are two aspects to the bento issue: 1) Somehow pip isn't picking up bento's egg info

Re: [Distutils] Comments on PEP 426

On 29 August 2013 16:49, Paul Moore p.f.mo...@gmail.com wrote: On 29 August 2013 16:02, Oscar Benjamin oscar.j.benja...@gmail.com wrote: On 29 August 2013 15:30, Antoine Pitrou anto...@python.org wrote: [...] (after all, it's just python setup.py build_bdist, or something :-)) The point

Re: [Distutils] Comments on PEP 426

On 30 August 2013 13:49, Daniel Holth dho...@gmail.com wrote: On Fri, Aug 30, 2013 at 7:54 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I just tried to install bento to test it out and: $ pip install bento Downloading/unpacking bento Downloading bento-0.1.1.tar.gz (582kB): 582kB

Re: [Distutils] Comments on PEP 426

On 29 August 2013 18:11, Daniel Holth dho...@gmail.com wrote: It probably makes sense for some version of bdist_wheel to be merged into setuptools eventually. In that system pip would document which setup.py commands and arguments it uses and a non-distutils-derived setup.py would have to

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

On 21 August 2013 22:22, Paul Moore p.f.mo...@gmail.com wrote: On 21 August 2013 22:13, Nick Coghlan ncogh...@gmail.com wrote: Wheel is a suitable replacement for bdist_wininst (although anything that needs install hooks will have to wait for wheel 1.1, which will support metadata 2.0). It's

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

On 22 August 2013 16:33, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote: 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

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

On 21 August 2013 08:04, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Oscar Benjamin oscar.j.benjamin at gmail.com writes: I think that they are responsible for installing the f2py script in each of my Scripts directories. I never use this script and I don't know what numpy wants with it (my

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

On 21 August 2013 11:39, Paul Moore p.f.mo...@gmail.com wrote: On 21 August 2013 11:29, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I may have misunderstood it but looking at this https://github.com/numpy/numpy/blob/master/tools/win32build/nsis_scripts/numpy-superinstaller.nsi.in#L147 I

[Distutils] Installing from a wheel

This is the first time that I've tested using wheels and I have a couple of questions. Here's what I did (is this right?): $ cat spam.py # spam.py print('running spam from:', __file__) $ cat setup.py from setuptools import setup setup(name='spam', version='1.0', py_modules=['spam'])

Re: [Distutils] Installing from a wheel

On 21 August 2013 14:08, Paul Moore p.f.mo...@gmail.com wrote: On 21 August 2013 13:59, Oscar Benjamin oscar.j.benja...@gmail.com wrote: $ cat spam.py # spam.py print('running spam from:', __file__) [snip] Looks good. You might want to add the (undocumented) universal flag to setup.cfg

Re: [Distutils] Installing from a wheel

On 21 August 2013 14:56, Paul Moore p.f.mo...@gmail.com wrote: On 21 August 2013 14:28, Oscar Benjamin oscar.j.benja...@gmail.com wrote: So I tried updating everything e.g.: $ pip install -U wheel pip setuptools [lots omitted for brevity] Some thoughts. pip 1.3.1 predates pip's wheel

Re: [Distutils] Installing from a wheel

On 21 August 2013 15:57, Daniel Holth dho...@gmail.com wrote: A fresh virtualenv would have been the humane way to get a working 'pip install wheel'. Good point. I think I learned an important point going through that upgrade mess though: uninstall/reinstall is safer than upgrade. Wheel's

Re: [Distutils] Installing from a wheel

On 21 August 2013 15:57, Paul Moore p.f.mo...@gmail.com wrote: On 21 August 2013 15:48, Oscar Benjamin oscar.j.benja...@gmail.com wrote: Is it perhaps safer to suggest the following? a) uninstall pip/setuptools/distribute b) run ez_setup.py c) run get-pip.py It probably is. I've heard

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

Paul wrote: Given that the installer includes the py.exe launcher, if you leave the defaults, then at a command prompt python doesn't work. But that's fine, because py does. And if you have multiple versions of Python installed, you don't *want* python on PATH, because then you have to manage

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

On 20 August 2013 09:51, Paul Moore p.f.mo...@gmail.com wrote: 1. Will the bundled pip go into the system site-packages or the user site-packages? Does this depend on whether the user selects install for all users or install for just me? If you have get-pip then why not choose at that point

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

On 20 August 2013 14:49, Nick Coghlan ncogh...@gmail.com wrote: On 20 Aug 2013 05:51, Paul Moore p.f.mo...@gmail.com wrote: But yes, if I made extensive use of binary extensions, I'd hate this approach. That's why I keep saying that the biggest win for wheels will be when they become the

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

On 20 August 2013 16:21, Paul Moore p.f.mo...@gmail.com wrote: On 20 August 2013 16:09, Oscar Benjamin oscar.j.benja...@gmail.com wrote: BTW is there any reason for numpy et al not to start distributing wheels now? Is any part of the wheel specification/tooling/infrastructure not complete yet

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

On 13 August 2013 20:58, Paul Moore p.f.mo...@gmail.com wrote: On 13 August 2013 18:08, Oscar Benjamin oscar.j.benja...@gmail.com wrote: On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote: On another point you mention, Cygwin Python should be using Unix-style shell script

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

On 14 August 2013 14:48, Paul Moore p.f.mo...@gmail.com wrote: But I do see your point regarding things like subprocess. It's a shame, but anything other than exes do seem to be second class citizens on Windows. BTW, you mention bat files - it bugs me endlessly that bat files seem to have a

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

On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote: On another point you mention, Cygwin Python should be using Unix-style shell script wrappers, not Windows-style exes, surely? The whole point of Cygwin is that it emulates Unix, after all... So I don't see that as an argument

Re: [Distutils] Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)

On 19 July 2013 20:48, Steve Dower steve.do...@microsoft.com wrote: From: Oscar Benjamin I don't know whether or not you intend to have wrappers also work for Python 2.7 (in a third-party package perhaps) but there is a slightly subtle point to watch out for when non-ASCII characters

Re: [Distutils] Q about best practices now (or near future)

On 17 July 2013 22:43, Nick Coghlan ncogh...@gmail.com wrote: On 18 Jul 2013 01:46, Daniel Holth dho...@gmail.com wrote: On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon br...@python.org wrote: I'm going to be pushing an update to one of my projects to PyPI this week and so I figured I

Re: [Distutils] Q about best practices now (or near future)

On 18 July 2013 13:13, Nick Coghlan ncogh...@gmail.com wrote: On 18 Jul 2013 21:48, Oscar Benjamin oscar.j.benja...@gmail.com wrote: In another thread you mentioned the idea that someone would build without using distutils/setuptools by using a setup.py that simply invokes an alternate build

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

On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote: On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote: 5. Support cross-compilation of extensions by default. TBH I don't know how much of this has anything to do with pip? As far as compiling goes all pip does is call

Re: [Distutils] PEP 426 updated based on last round of discussion

On 16 July 2013 14:40, Nick Coghlan ncogh...@gmail.com wrote: The latest version of PEP 426 is up at http://www.python.org/dev/peps/pep-0426/ Just looking at the Build requires section I found myself wondering: is there any way to say that e.g. a C compiler is required for building, or a

Re: [Distutils] PEP 426 updated based on last round of discussion

On 17 July 2013 12:10, Paul Moore p.f.mo...@gmail.com wrote: I can't imagine it's practical to auto-install a C compiler Why not? - or even to check for one before building. But I can see it being useful for introspection purposes to know about this type of requirement. (A C compiler

Re: [Distutils] PEP 426 updated based on last round of discussion

On 17 July 2013 13:17, Nick Coghlan ncogh...@gmail.com wrote: That said, the new metadata standard does deliberately include a few pieces intended to make such things easier to define: 1. The extensions concept - using a structured data format like JSON makes it much easier for platform

Re: [Distutils] Q about best practices now (or near future)

On 17 July 2013 19:46, Barry Warsaw ba...@python.org wrote: On Jul 17, 2013, at 11:46 AM, Daniel Holth wrote: I'd like to see an ambitious person begin uploading wheels that have no traditional sdist. You're not getting rid of sdists are you? Please note that without source distributions

Re: [Distutils] Q about best practices now (or near future)

On 17 July 2013 20:39, Barry Warsaw ba...@python.org wrote: On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote: I imagined that distro packaging tools would end up using the wheel as an intermediate format when building a deb from a source deb. Do you mean, the distro would download the wheel

Re: [Distutils] Q about best practices now (or near future)

On 17 July 2013 20:52, Daniel Holth dho...@gmail.com wrote: On Wed, Jul 17, 2013 at 3:39 PM, Barry Warsaw ba...@python.org wrote: On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote: I imagined that distro packaging tools would end up using the wheel as an intermediate format when building a deb

Re: [Distutils] Q about best practices now (or near future)

On 17 July 2013 17:59, Brett Cannon br...@python.org wrote: But it also sounds like that project providing wheel distributions is too early to include in the User's Guide. There are already many guides showing how to use distutils/setuptools to do things the old way. There are also confused

Re: [Distutils] Replacing pip.exe with a Python script

On 16 July 2013 11:28, Paul Moore p.f.mo...@gmail.com wrote: Two thoughts for the wider audience: 1. Should pip re-vendor a newer version of distlib, so we have the exe wrappers? We currently have 0.1.1 and 0.1.2 is on PyPI. In what way would that affect anyone? 2. Would writing a distutils

Re: [Distutils] Replacing pip.exe with a Python script

On 16 July 2013 12:25, Paul Moore p.f.mo...@gmail.com wrote: 2. Would writing a distutils extension class in setup.py to make the exe wrappers using the vendored distlib.scripts package be acceptable to remove the runtime dependency on pkg_resources from the wrappers? Does that mean

Re: [Distutils] Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)

On 16 July 2013 16:22, Paul Moore p.f.mo...@gmail.com wrote: On 16 July 2013 16:09, Oscar Benjamin oscar.j.benja...@gmail.com wrote: However, if you also want the program name to be invokable from e.g. subprocess with shell=False or from git-bash or Cygwin or many other things then neither

Re: [Distutils] Wheels and console script entry point wrappers (Was: Replacing pip.exe with a Python script)

On 16 July 2013 14:38, Paul Moore p.f.mo...@gmail.com wrote: On 16 July 2013 14:30, Ronald Oussoren ronaldousso...@mac.com wrote: I think the correct solution is to explicitly have declarative support for console script entry point metadata in PEP 426, as well as having tools like

  1   2   >