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.
> h
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 provide feedback, and
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
> I'm going to mark i
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 then we'll see conf
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
> have my sources in s
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 would be full of surprising and confusing
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:
> https://mail.python.org/pipermail/linux-sig/2015-October/00.ht
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
> https://docs.python.org/3/installing/index.html#basic-usage and it is not
> particularly helpful i
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 - CPU was some budget AMD model)
>> > """
>> >
>>
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 get better performance treatment, though I'm n
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 unless the
compiler
On Sat, 10 Oct 2015 23:37 Laura Creighton 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
>reason
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, and
windows 7, you
On Fri, 9 Oct 2015 19:35 Carl Meyer 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 and each wheel declare
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 file format.
>
> A "source wheel" is the p
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 how Debian does.
>> e.g.
>> numpy-1.0.n
On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote:
> On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin
> wrote:
>>
>> I think this satisfies all of the requirements for static metadata and
>> one-to-one correspondence of source wheels and binary wheels. If numpy
On 8 October 2015 at 12:46, Paul Moore wrote:
> On 8 October 2015 at 11:18, Oscar Benjamin wrote:
>>
>> A concrete example would be whether or not the numpy source wheel
>> depends on pyopenblas. Depending on how numpy is built the binary
>> wheel may or may not depen
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 not, but I don't think anyone's pointed
On Wed, 7 Oct 2015 19:42 Donald Stufft 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 correspondence with binary
>
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 release)
> as something fo
the module file:
>
> 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"
> To:
Should the function be called init_spam rather than initspam?
On Tue, 18 Aug 2015 19:19 garyr 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 shown the code c
On Fri, 24 Jul 2015 at 19:53 Chris Barker 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
On Fri, 17 Jul 2015 at 16:37 Chris Barker 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)
>
>
> - Packages with semi-standard dependencies: can we expect ANY Linux
> distro to have libfreetype,
On 19 May 2015 at 10:55, Paul Moore 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 statically link
On 19 May 2015 at 03:24, salil GK wrote:
>
>I was trying to create my package for distribution. I have a requirement
> that I need to check if one particular command is available in the system (
> this command is not installed through a package - but a bundle is installed
> to get the command
On 2 March 2014 21:05, Nick Coghlan 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 the d
On 2 March 2014 07:25, Nick Coghlan 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 hold up the res
On 21 February 2014 13:24, Paul Moore 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?
>
> sysconfig.get_path("scripts") sho
On 24 January 2014 10:18, Nick Coghlan wrote:
>
> On 24 Jan 2014 19:41, "Paul Moore" wrote:
>>
>> On 24 January 2014 00:17, Oscar Benjamin
>> wrote:
>> > You need to bear in mind that people currently have a variety of ways
>> > to i
On 24 January 2014 22:40, Paul Moore wrote:
> On 24 January 2014 22:21, Chris Barker 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 up to build extensions at all, but
On 23 January 2014 23:58, Nick Coghlan 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 proportion of
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 si
On 6 December 2013 13:54, Nick Coghlan wrote:
> On 4 December 2013 21:10, Nick Coghlan 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
>> that once a couple of secur
On 6 December 2013 13:06, David Cournapeau 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
> installers for num
On 5 December 2013 00:06, Marcus Smith 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 with
On 4 December 2013 20:56, Ralf Gommers wrote:
> On Wed, Dec 4, 2013 at 5:05 PM, Chris Barker - NOAA Federal
> 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 around a
>> while (long while in comp
On 4 December 2013 12:10, Nick Coghlan wrote:
> On 4 December 2013 20:41, Oscar Benjamin 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
>> suggest
On 4 December 2013 07:40, Ralf Gommers wrote:
> On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft 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 to help get
> to that point f
On 3 December 2013 21:13, Donald Stufft 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. Very few pack
On 3 December 2013 22:18, Chris Barker wrote:
> On Tue, Dec 3, 2013 at 12:48 AM, Nick Coghlan 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, users are going to remain confu
On 3 December 2013 13:53, Nick Coghlan wrote:
> On 3 December 2013 22:49, Oscar Benjamin 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 a bunch of t
On 3 December 2013 11:54, Nick Coghlan wrote:
> On 3 December 2013 21:22, Oscar Benjamin wrote:
>> AFAICT conda/binstar are alternatives for pip/PyPI that happen to host
>> binaries for some packages that don't have binaries on PyPI. (conda
>> also provides a differen
On 1 December 2013 04:15, Nick Coghlan 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 impact securi
On 3 December 2013 10:19, Nick Coghlan 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 wheel, so this
On 2 December 2013 13:54, Paul Moore 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 binaries - there
On 2 December 2013 09:19, Paul Moore wrote:
> On 2 December 2013 07:31, Nick Coghlan 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 the clarification.
>
> Can I su
On Dec 1, 2013 1:10 PM, "Paul Moore" wrote:
>
> On 1 December 2013 04:15, Nick Coghlan 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 binaries (currently administered
On Oct 31, 2013 8:50 PM, "Tres Seaver" 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 all platf
On Oct 31, 2013 4:09 PM, "Dominique Orban"
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 Orban"
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
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
> in the PyPi documentation or in Google searches. I uploaded my package
> `pykrylov` with `python setup.py sdist upload`. Installing it locally with
> `python setup
On 21 October 2013 11:38, Thomas Güttler 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 me. Why don
On 17 October 2013 16:53, Donald Stufft wrote:
>
> On Oct 17, 2013, at 11:49 AM, Michael Foord 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
> gets sent to /dev/null" in
On 18 September 2013 15:26, Nick Coghlan 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 base Python inst
On 16 September 2013 12:27, Nick Coghlan wrote:
>
> On 16 Sep 2013 19:55, "Oscar Benjamin" wrote:
>>
>> I still don't understand why this is preferable to just shipping a
>> recent stable pip/setuptools and providing instructions to update
>> post-in
On 15 September 2013 16:33, Donald Stufft 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
> whose purp
On 8 September 2013 12:07, Paul Moore wrote:
> On 7 September 2013 23:36, Carl Meyer 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 issue, injecting setuptools ac
On 5 September 2013 13:34, Daniel Holth wrote:
> On Thu, Sep 5, 2013 at 5:36 AM, Oscar Benjamin
> wrote:
>
> --single-version-externally-managed just means "install everything
> into a flat site-packages" rather than installing them into their own
> (egg) directori
On 4 September 2013 19:16, Éric Araujo wrote:
> Le 30/08/2013 03:23, Paul Moore a écrit :
>> On 30 August 2013 00:08, Nick Coghlan wrote:
>>> We also need to officially bless pip's trick of forcing the use of
>>> setuptools for distutils based setup.py files.
>> Do we? What does official blessing
On 4 September 2013 13:51, Paul Moore wrote:
> On 4 September 2013 12:58, Nick Coghlan 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 implementation that could be used to rep
On 4 September 2013 12:20, Paul Moore wrote:
> On 4 September 2013 12:05, Oscar Benjamin 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 the distutils monkey-patch
On 4 September 2013 11:30, Donald Stufft wrote:
>
> On Sep 4, 2013, at 6:21 AM, "M.-A. Lemburg" 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 the
>> setup.py code (a
On 4 September 2013 08:51, M.-A. Lemburg wrote:
> On 04.09.2013 09:27, Paul Moore wrote:
>> On 4 September 2013 08:13, M.-A. Lemburg wrote:
>>
>>> I guess that's what the suggestion is all about: avoiding
>>> reinventing the wheel, endless discussions and instead going
>>> for standard software r
On 31 August 2013 16:18, Nick Coghlan 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 directory.
2) There's
On 31 August 2013 16:03, Antoine Pitrou wrote:
> Oscar Benjamin 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
&
On 31 August 2013 14:24, Antoine Pitrou wrote:
> Oscar Benjamin 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 t
On 31 August 2013 12:03, Antoine Pitrou wrote:
> Donald Stufft 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 install somet
On 30 August 2013 13:49, Daniel Holth wrote:
> On Fri, Aug 30, 2013 at 7:54 AM, Oscar Benjamin
> wrote:
>>
>> I just tried to install bento to test it out and:
>>
>> $ pip install bento
>> Downloading/unpacking bento
>> Downloading bento-0.1.1.tar
On 29 August 2013 16:49, Paul Moore wrote:
> On 29 August 2013 16:02, Oscar Benjamin wrote:
>>On 29 August 2013 15:30, Antoine Pitrou wrote:
> [...]
>>> (after all, it's just "python setup.py build_bdist", or something :-))
>>
>> The point is tha
On 29 August 2013 18:11, Daniel Holth 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 implement a minim
On 29 August 2013 15:30, Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>
>> >> This version of the metadata specification continues to use ``setup.py``
>> >> and the distutils command syntax to invoke build and test related
>> >> operations on a source archive or VCS checkout.
>> >
>> >
On 22 August 2013 16:33, Chris Barker - NOAA Federal
wrote:
> On Thu, Aug 22, 2013 at 6:52 AM, Oscar Benjamin
> wrote:
>
>> I'm pretty sure the current Windows installer just doesn't bother with
>> BLAS/LAPACK libraries. Maybe it will become possible to expo
On 22 August 2013 12:57, Vinay Sajip wrote:
>> I think that the installer ships variants for each architecture and
>> decides at install time which to place on the target system. If that's
>> the case then would it be possible for a wheel to ship all variants so
>> that a post-install script could
On 21 August 2013 22:22, Paul Moore wrote:
> On 21 August 2013 22:13, Nick Coghlan 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 just not a replacement for wh
On 21 August 2013 15:57, Paul Moore wrote:
> On 21 August 2013 15:48, Oscar Benjamin 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'
On 21 August 2013 15:57, Daniel Holth 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 built in instal
On 21 August 2013 14:56, Paul Moore wrote:
> On 21 August 2013 14:28, Oscar Benjamin 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
On 21 August 2013 14:08, Paul Moore wrote:
> On 21 August 2013 13:59, Oscar Benjamin wrote:
>>
>> $ cat spam.py
>> # spam.py
>> print('running spam from:', __file__)
[snip]
>
> Looks good. You might want to add the (undocumented) universal flag to
&g
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'])
On 21 August 2013 11:39, Paul Moore wrote:
> On 21 August 2013 11:29, Oscar Benjamin 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
>>
On 21 August 2013 08:04, Vinay Sajip wrote:
> Oscar Benjamin 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 u
On 20 August 2013 16:21, Paul Moore wrote:
> On 20 August 2013 16:09, Oscar Benjamin 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?
>
&g
On 20 August 2013 14:49, Nick Coghlan wrote:
>
> On 20 Aug 2013 05:51, "Paul Moore" 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 common means of distributing
On 20 August 2013 09:51, Paul Moore 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 whether you wan
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
On 14 August 2013 14:48, Paul Moore 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 more privileged
On 13 August 2013 20:58, Paul Moore wrote:
>
> On 13 August 2013 18:08, Oscar Benjamin wrote:
>>
>> On 13 August 2013 17:33, Paul Moore wrote:
>> >
>> > On another point you mention, Cygwin Python should be using Unix-style
>> > shell
>> >
On 13 August 2013 17:33, Paul Moore 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
> either way.
So say
On 19 July 2013 20:48, Steve Dower 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 charac
On 18 July 2013 13:13, Nick Coghlan wrote:
>
> On 18 Jul 2013 21:48, "Oscar Benjamin" 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 b
On 17 July 2013 22:43, Nick Coghlan wrote:
>
> On 18 Jul 2013 01:46, "Daniel Holth" wrote:
>>
>> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
>> > I'm going to be pushing an update to one of my projects to PyPI this
>> > week
>> > and so I figured I could use this opportunity to help wi
On 17 July 2013 17:59, Brett Cannon 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 bits of
document
On 17 July 2013 20:52, Daniel Holth wrote:
> On Wed, Jul 17, 2013 at 3:39 PM, Barry Warsaw 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
On 17 July 2013 20:39, Barry Warsaw 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 do
On 17 July 2013 19:46, Barry Warsaw 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 (preferabl
On 17 July 2013 13:17, Nick Coghlan 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 specific tools (or
On 17 July 2013 12:10, Paul Moore 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
> could be necessar
On 16 July 2013 14:40, Nick Coghlan 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 Fortran compiler o
1 - 100 of 118 matches
Mail list logo
