On 19 May 2015 at 20:26, Chris Barker wrote:
> This entire conversation is about when the build dependencies are NOT simple
> :-). And while it may be project specific, commonly used libs are not
> project specific, and they are where the time and pain are. So some shared
> infrastructure would be
On 19 May 2015 at 21:19, Wes Turner wrote:
> Would this be different than:
>
> # miniconda
> conda install pip
> conda install scientific_stuff
> pip install django_widget
Having tried that in the past, I can say that I *very* rapidly got
completely lost as to which packages I'd i
On 19 May 2015 at 22:29, Chris Barker wrote:
> As far as I can tell, Continuum does not publish the build scripts used to
> build all the stuff in Anaconda.
So, for example the process for building the pyyaml package available
via conda is private? (I want to say "proprietary", but there's a lot
Sigh. I really am going to try to stop monopolising this thread - but
you keep making good points I feel I "have" to respond to :-) I'll try
to keep to essentials.
On 19 May 2015 at 22:11, Chris Barker wrote:
> On Tue, May 19, 2015 at 10:58 AM, Paul Moore wrote:
> you c
On 19 May 2015 at 23:32, Chris Barker wrote:
> lost track of where in the thred this was, but here's a conda recipe I found
> on gitHub:
>
> https://github.com/menpo/conda-recipes/tree/master/libxml2
>
> don't know anything about it.
OK, I'm still misunderstanding something, I think. As far a
On 20 May 2015 at 00:04, Chris Barker wrote:
> yup. which makes me think -- maybe not that hard to do a wininst to wheel
> converter for wxPython -- that would be nice. We also need it for the Mac,
> and that would be harder -- he's got some trickery in placing the libs in
> that one...
"wheel co
On 20 May 2015 at 15:53, David Mertz wrote:
> It's not *only* the 'setup.py install', but it's not *that* much mystery
> either. wxPython I can't seem to find, not sure what I'm missing.
Yeah, I had been under the impression that there was a lot of
knowledge on how to build the dependencies (thi
On 21 May 2015 at 16:37, Donald Stufft wrote:
> Also, one of the goals a few of us has in the PyPA is that we move to a
> future where the build systems are pluggable. So one package could be
> building using setuptools, another building using some SciPy specific build
> tool, another using a who
On 21 May 2015 at 20:26, Chris Barker wrote:
> Now that I think about it, it may seem kludgy, but conda packages can be
> built from wheel right now, with no special tools. A conda recipe that
> simply installs a wheel in it's build script would do just that.
That sounds about right, from what I'
On 21 May 2015 at 23:49, Chris Barker wrote:
> On Thu, May 21, 2015 at 1:12 PM, Paul Moore wrote:
>> Some possible problem areas - when you install a wheel, it will
>> install executable wrappers for the entry points (like pip.exe) which
>> are tied to the install locatio
On 22 May 2015 at 05:21, Donald Stufft wrote:
> I'm happy to say that I've just cut the releases of pip 7.0 and virtualenv
> 13.0
> and I have uploaded them to PyPI. For the full list of changes go visit the
> respective changelogs, however the biggest change here is that in pip 7.0 when
> pip fi
On 28 May 2015 at 22:49, Peter Hodges wrote:
> I would appreciate any suggestions on how to proceed.
If you downloaded Python 3.5, you should have pip available to you (I
use Windows, so I'm not 100% sure how the OSX installers handle it,
but it should be there).
With pip, you should be able to
On 9 June 2015 at 20:09, Robert Collins wrote:
> I'm in favour of it - it fits the existing wheel spec; its opt-in,
> non-intrusive and solves a real, present problem. [just not the 'how
> do we get these damn things into PyPI, yet].
Agreed, it sounds like a reasonable approach.
One thought - ra
On 9 June 2015 at 21:35, Robert Collins wrote:
> I don't see a space for that in PEP 427; so that might be an option in
> future but not compatible with wheel 1.0 AIUI.
Good point. We can revisit this for Wheel 2.0, but practicality beats
purity for now so I'm OK with using the platform tag on th
On 19 June 2015 at 18:19, Dimitri Maziuk wrote:
> Well, it could be mentioned in the "eggsecutable scripts" section, esp.
> since what that has now doesn't really parse anyway:
While I understand what you want, and it sounds like you have found a
way to achieve it, Daniel is right - this feature
On 19 June 2015 at 21:24, Dimitri Maziuk wrote:
> So add a bdist_zip target and have it output a .zip without egg-info
> cruft instead of making people like me reinvent the wheel every !@#$ing
> time. Even if the wheel is as simple as piping glob.glob into a zipfile
> -- which it never is IRL.
Th
On 27 June 2015 at 19:52, Justin Uang wrote:
> What is the recommended way to get access to a data file in my package if
> I'm using a wheel? pkg_resources seems like it's mainly useful because eggs
> might be used in a zipped form, but for wheels, I'm guaranteed that the data
> will be unpacked i
On 29 June 2015 at 07:56, Paul Sokolovsky wrote:
>> If you want to avoid a dependency on pkg_resources, you can use
>> pkgutil.get_data (from the stdlib). It doesn't have as many features
>> as pkg_resources, but it does the job in straightforward cases.
>
> Which makes everyone in the audience wo
On 29 June 2015 at 10:26, Paul Sokolovsky wrote:
> and yet we're stuck at the old base PEPs which
> overlooked providing stream access protocol for package resources
> access.
The PEP did not "overlook" stream access. Rather, the compatibility
constraints and the need to support existing code mea
On 6 July 2015 at 17:24, Antoine Pitrou wrote:
> (yes, the version number is off - but that's besides the point here,
> I think):
>
> $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl
> /home/antoine/.local/lib/python3.4/site-packages/pkginfo/installed.py:53:
> UserWarning: No PKG-
On 6 July 2015 at 19:18, Antoine Pitrou wrote:
> What if packagers take care of working around the issue?
> (for example by building on a suitably old Linux platform, as we
> already do for Conda packages)
At the moment it's just a simple "if the wheel is for Linux, reject it" test.
As to whethe
On 18 July 2015 at 02:13, Chris Barker - NOAA Federal
wrote:
>> Someone needs to write that specification. Propose we forget about Windows
>> for the first revision, so that it is possible to get it done.
>
> If we want Windows support in the long run -- and we do -- we should
> be thinking about
On 20 July 2015 at 18:37, Chris Barker wrote:
> sure -- but isn't that use-case already supported by wheel -- define your
> own wheelhouse that has the ABI you know you need, and point pip to it.
I presume the issue is wanting to have a single shared wheelhouse for
a (presumably limited) number o
On 17 August 2015 at 18:12, Erik Bray wrote:
> On Thu, Aug 13, 2015 at 4:42 AM, 俞博文 wrote:
>> Dear Maintainers:
>>
>> This problem occurred when
>> 1. Windows platform
>> 2. Python is installed on non-Latin path (for example: path contains Chinese
>> character).
>> 3. try to "pip install theano"
On 26 August 2015 at 16:10, Piotr Dobrogost
wrote:
> After `pip install js.deform==2.0a2-3` I get the message "Successfully
> installed js.deform-2.0a2.post3" where version "2.0a2-3" was
> normalized (I guess) to "2.0a2.post3" and that's the version pip list
> reports as well. Due to this PyCharm
On 27 August 2015 at 02:24, Donald Stufft wrote:
> While developing Warehouse, one of the things I wanted to get done was a
> final ruling on PEP 470. With that in mind I’d like to bring it back up for
> discussion and hopefully ultimately a ruling.
>
> Their are two major differences in this ve
On 27 August 2015 at 12:51, Donald Stufft wrote:
> Perhaps you could suggest a rewording that you think says the above? I don’t
> see a political view being implied nor do I see the needs of US users being
> prioritized over the needs of non-US users.
Just for perspective, I didn't read that se
On 27 August 2015 at 02:24, Donald Stufft wrote:
> I do need a BDFL Delegate for this PEP, Richard does not have the time to do
> it and the other logical candidate for a PyPI centric PEP is myself, but I
> don’t feel it’s appropriate to BDFL Delegate my own PEP.
I've agreed to be BDFL-Delegate
On 27 August 2015 at 12:53, Donald Stufft wrote:
> We can add documentation, it’s basically “stick some files in a directory,
> run python -m http.server”, adjusted for someone’s need for performance and
> “production” readiness. We make it pretty easy to make one with —find-links,
> any old we
On 30 August 2015 at 05:48, Nick Coghlan wrote:
>> The devil's in the details, though.
>>
>> * Do I need to use canonical names for packages in my index? Assuming
>> so, what *are* the rules for a "canonical name"?
>
> This is a good point - even if folks are hosting externally, we still
> want th
On 31 August 2015 at 11:59, Wichert Akkerman wrote:
> Sure. My knowledge of rpm is 20 years out of date, so I am going to focus
> the deb/dpkg/apt world only. The whole packaging system is build around
> archives. The packaging tools themselves do not have anything hardcoded
> there, they pick up
On 1 September 2015 at 07:26, Nathaniel Smith wrote:
> Looking at the download url that PyPI points to:
>
>http://www.pygame.org/download.shtml
>
> then I get the impression that this page was designed to be read by
> humans only, and if pip/easy_install ever do anything useful with it
> then
There has been no further feedback on PEP 470, and Donald has
incorporated all the feedback, so I'm happy to announce that I am
approving it.
The PEP is available in the usual place at
https://www.python.org/dev/peps/pep-0470/.
Thanks to all who participated in the various threads on the subject,
On 5 September 2015 at 17:15, Donald Stufft wrote:
> I've updated the PEP with the typo corrections, clarifications, and the
> missing
> GPG signature support that Marc-Andre and Marius pointed out. It should be
> live
> on the PEP site soon, but the diff can be viewed online at
> https://hg.pyt
On 20 September 2015 at 20:43, OmPs wrote:
> It says no matching distribution, but at pypi repo I am able to see it.
>
> https://pypi.python.org/pypi/atfork/0.1.2
However, there are no download files available. The home page says
that the project has been abandoned.
Paul
_
On 27 September 2015 at 11:20, Thomas Güttler
wrote:
> Any good reason to **not** use README.rst but a different
> name like DESCRIPTION.rst?
If I recall, the reason for using DESCRIPTION.rst is that README.rst
is used by other tools (for example, github) and it's not immediately
obvious that the
On 27 September 2015 at 18:05, Thomas Güttler
wrote:
>> In practice, the sample project is not expected to be treated as
>> definitive, so I don't think it matters that much if people use a
>> different name.
>
> OK, the sample project is not the definitive guide line.
> Where can I find the defin
On 2 October 2015 at 20:02, Marcus Smith wrote:
>> So wouldn't they then download the sdist, build a wheel as an
>> intermediate, and then generate the .deb file?
>
> the new goal I think was to have standardized metadata immediately available
> in an sdist, and get away from the model, that you h
On 2 October 2015 at 20:45, Donald Stufft wrote:
> n October 2, 2015 at 2:41:20 PM, Brett Cannon (br...@python.org) wrote:
>> > Is there another proposal I'm unaware for the sdist -> wheel
>> step that is build tool-agnostic? I'm all for going with the best
>> solution but there has to be an actua
On 2 October 2015 at 21:19, Nathaniel Smith wrote:
>> One of the problems with the current system, is that we have no mechanism by
>> which to determine dependencies of a source distribution without downloading
>> the file and executing some potentially untrusted code. This makes dependency
>> res
On 2 October 2015 at 22:45, Nathaniel Smith wrote:
>> I'm uncomfortable with the fact that the proposed sdist format has
>> more or less no metadata of its own (even the filename format is only
>> a recommendation) so (for example) if someone does "pip install
>> foo==1.0" I don't see how pip can
On 2 October 2015 at 23:15, Nathaniel Smith wrote:
> "Project" is a pretty messy concept. Obviously in simple cases there's
> a one-to-one mapping between project <-> wheel <-> importable package,
> but this breaks down quickly in edge cases.
I mistakenly used "project" in an attempt to avoid con
On 3 October 2015 at 02:03, Nathaniel Smith wrote:
> In particular I hesitate a little bit to just drop in everything from
> PEP 426 and friends, because previous specs haven't really thought
> through the distinction between sdists and wheels -- e.g. if an sdist
> generates two wheels, they proba
Let me see if I can help clarify, so it's not just Donald who says so :-)
It does feel as if we're trying to explain a lot of things that
"everybody knows". Clearly not everybody knows, as you don't, but what
we're trying to clarify here is the de facto realities of how sdists
work, and how people
On 5 October 2015 at 07:29, Nathaniel Smith wrote:
> First, let's drop the word "sdist", it's confusing.
I'll read your full reply later, when I have the time, but please note
we can't drop the term sdist - it's a well known concept in packaging.
Having said that, I'm happy if you want to restat
OK, I've had a better read of your email now. Responses inline.
On 5 October 2015 at 07:29, Nathaniel Smith wrote:
> First, let's drop the word "sdist", it's confusing.
We can't (see below for details). We can deprecate the sdist concept,
if that's what you want to propose. From what I gather, y
On 5 October 2015 at 13:44, Donald Stufft wrote:
> [3] Unlike Paul, I think a Source Wheel is actually a decent name for this
> concept. It's similar to .rpm and .src.rpm in that world, and I think it
> makes it more obvious that this item isn't an installable item in it's own
> right,
On 5 October 2015 at 14:25, Donald Stufft wrote:
> The main thing I wanted was something that wasn't a mouthful to say and that
> had a dedicated extension so we don't end up where the filename looks
> incredibly generic (requests-1.0.swhl vs requests-1.0.tar.gz).
You find "Source Wheel" easier t
On 6 October 2015 at 08:51, Antoine Pitrou wrote:
> They should be inside the module. That way, you can check an installed
> module is ok by running e.g. "python -m mypackage.tests". Any other
> choice makes testing installed modules more cumbersome.
One inconvenience with this is that if you use
On 6 October 2015 at 14:51, David Cournapeau wrote:
>> Of course, the same argument can be made for installing tests, since it's
>> not
>> very common.
>
>
> So we can actually get some data here :)
>
> At Enthought, we support around 400 packages. More than half of them are
> python packages, and
On 6 October 2015 at 15:27, Jeremy Stanley wrote:
> It seems rather optimistic to assume that 100% of projects have test
> suites. More accurately, 75% either have no tests _or_ keep them
> outside the package. ;)
I'm having a happy day today - don't spoil it... :-)
Paul
_
On 7 October 2015 at 18:27, Nathaniel Smith wrote:
> There are projects on PyPI right now, today, that have no way to
> generate sdists and will never have any need for "source wheels"
I think I'm as confused by what you're saying here as Donald is. Could
you give a few examples of such projects?
On 7 October 2015 at 20:36, Oscar Benjamin wrote:
> Currently I can take the code from the numpy release and compile it in
> different incompatible ways. For example I could make a wheel that bundles a
> BLAS library. Or I could make a wheel that expects to use a system BLAS
> library that should
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 to any examples yet
> of the problems that pip is en
On 7 October 2015 at 22:53, Nathaniel Smith wrote:
>> I think I'm as confused by what you're saying here as Donald is. Could
>> you give a few examples of such projects? I'd like to go & take a look
>> at them and try to understand what they are doing that is so
>> incompatible with what Donald an
On 8 October 2015 at 11:18, Oscar Benjamin wrote:
> 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
On 8 October 2015 at 13:39, Oscar Benjamin wrote:
> 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 pyope
On 9 October 2015 at 10:32, Thomas Güttler wrote:
> My question was: Any reasons not to use tox in the sample project?
1. Because the sample project is intended to explain how to *package*
a project, not how to test it, or document it, or any of a number of
other non-packaging things.
2. Because
"""
It may be good to add a footnote with your "For more exhaustive
examples..." comment - but it would need links, and good luck on
getting any sort of agreement on what constitutes good examples :-)
Paul
On 9 October 2015 at 11:11, Ionel Cristian Mărieș wrote:
>
&g
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 proposed name for a to-be-defined replacement
for sdists. For now, you can think of "source whe
On 9 October 2015 at 18:04, Chris Barker wrote:
> Which seems to point more to having an optional "binary_build" component to
> the name. Not sure what syntax is available, but the idea would be that:
>
> "numpy|mkl"
>
> and
>
> "numpy|openblas"
>
> would both match "numpy"
>
> which, of course wo
You could, I suppose, patch your custom Python to *not* treat wheels
built for cp35-none-win32 (or cp35-none-win_amd64, as appropriate) as
compatible with that build (that requires a patch to the tag matching
code in pip). You then wouldn't be able to use any binary wheels on
PyPI, which is a bit h
On 11 October 2015 at 05:01, Nathaniel Smith wrote:
> There's no formal proposal because it doesn't involve distutils-sig --
> it's something that we already know how to do and are working on
> implementing :-). The only reason it doesn't already exist on PyPI is
> that Windows is the main target,
On 11 October 2015 at 05:31, Nathaniel Smith wrote:
> Do the relevant pip maintainers
> even read this mailing list? :-)
Donald and I are pip maintainers (not the only ones, but probably the
ones who make the most noise on this list :-)). The comments I've made
that you quoted are based mostly on
On 11 October 2015 at 19:37, Robert Collins wrote:
> 'pip install --only-binary :all: THINGTOINSTALL' will do exactly what
> you want I think in that it will only download wheels.
ooh, I didn't spot that getting added! Many thanks for that.
Paul
___
Di
On 12 October 2015 at 08:23, Nathaniel Smith wrote:
> I mean the distribution name - there's no way to guarantee that
> building foo-1.0.zip won't spit out bar-7.4.whl, where by "no way" I
> mean "it's literally undecideable". I mean, if someone actually did
> this it would be super weird and we w
On 12 October 2015 at 07:14, Nathaniel Smith wrote:
> On Sun, Oct 11, 2015 at 10:55 PM, Marcus Smith wrote:
>>>
>>> So instead, the current plan is that we're going
>>> to drop the libraries inside a wheel and upload it to PyPI:
>>
>> aha... ok, now it's clearer where you're coming from.
>> but u
On 14 October 2015 at 01:46, Robert Collins wrote:
> On 14 October 2015 at 13:25, Marcus Smith wrote:
>>
>>
>> thanks for the summary!
Agreed.
>>
>>> * Things that have reason to change (deps) are more reasonable to be
>>> dynamic (even with PEP-426 markers there are exceptions)
>>
>>
>> as w
On 14 October 2015 at 09:50, Robert Collins wrote:
> For illustration, consider a numpy extension, the version of numpy
> present in the build environment determines some of the
> install-requires. The sdist can build against a much wider range of
> numpy versions than the resulting binary can run
On 14 October 2015 at 19:27, Donald Stufft wrote:
> I suspect it’d be trivial to relicense it. There’s a total of 6 contributors
> and I think I know how to get ahold of all of them.
I only contributed a tiny bit, but I'm happy for you to relicense if
you want to.
Paul
__
On 14 October 2015 at 19:48, Matthew Brett wrote:
> I'm guessing that this is what y'all expected?
Yes, that sounds right. 1.10.0.post2 is a new (different) release
number, and so a new release would be created.
Paul
___
Distutils-SIG maillist - Distu
On 21 October 2015 at 12:52, Thomas Güttler
wrote:
> ok, at the moment setuptools uses distutils.
>
> Why not melt them together into **one** underwear-pants-module?
(1) because there's no-one with anything like the time or energy to do
such a thing
(2) because doing so would almost certainly bre
On 21 October 2015 at 17:42, Chris Barker wrote:
> So why not have a setuptools-lite that only does the building? We need to
> keep the full over-burdened setuptools around, because lot sof folks are
> using those features. But for those of us that are doing something fairly
> new, and don't want
On 21 October 2015 at 20:32, Chris Barker wrote:
> I have no idea how we can get from here to there cleanly, but it would it be
> that big a deal for pip to look for either setuptools or setuptools_lite,
> and neither are there, inject setuptools_lite.
Yes it would, unfortunately. The problem is
On 21 October 2015 at 20:41, Chris Barker wrote:
> As I understand it, the current "API" that pip knows about is:
>
> "some subset of what setuptools provides"
>
> So my proposal is here is to provide a way for users to easily use jsut that
> subset.
https://pip.pypa.io/en/stable/reference/pip_in
On 21 October 2015 at 22:25, Antoine Pitrou wrote:
> Reading this, the CLI options which have to be implemented are
> completely tied to setuptools' own view of the world.
> `--single-version-externally-managed`? `--install-headers`? Why should
> a random build system care about that gunk? What sh
On 22 October 2015 at 19:45, Marcus Smith wrote:
> Mainly, I I think it should consist of a set of links to Issues and PRs in
> the PyPA PEP Repor [1], and links to major things going on in pip,
> setuptools, etc...
>
> Give me some +1s folks, and I'm willing to crank it up again... and rally
> fo
On 24 October 2015 at 20:25, Marcus Smith wrote:
> As someone who has slowly chipped away on the PyPUG for the last 2 years,
> I'm excited about the prospect of being able to make a big jump in quality
> very quickly.
Agreed - this is great news :-)
Paul
__
On 26 October 2015 at 06:04, Nathaniel Smith wrote:
> Here's a second round of text towards making a build-system
> independent interface between pip and source trees/sdists. My idea
> this time is to take a divide-and-conquer approach: this text tries to
> summarize all the stuff that it seemed l
On 27 October 2015 at 13:12, Daniel Holth wrote:
> We must do the hard work to support Unicode file names, and spaces and
> accent marks in home directory names (historically a problem on Windows), in
> our packaging system. It is the right thing to do. It is not the publisher's
> fault that your
On 28 October 2015 at 06:34, Robert Collins wrote:
>> 1) *Please*, *please*, *please* let's start doing PEP conversations as PRs
>> to pypa/interoperability-peps : ) There's a place in there for unnumbered
>> PEPs. Review will be better and faster IMO as PRs. If the PR gets too
>> cluttered w
On 28 October 2015 at 18:33, Ian Cordasco wrote:
> Also nothing precludes mailing list discussions, so without details
> about your objections, I don't see why this should be held up.
One immediate question - not at all FUD, nor intended as provocative,
it's a genuine question.
I thought right n
On 28 October 2015 at 18:27, Ionel Cristian Mărieș wrote:
> On Wed, Oct 28, 2015 at 10:31 AM, M.-A. Lemburg wrote:
>>
>> I agree with Ben. Discussions on PEPs need to happen on mailing lists,
>> not hidden away on some issue tracker or PR ticket.
>
>
> I think some balance is needed here. Every s
On 28 October 2015 at 18:44, Donald Stufft wrote:
> On October 28, 2015 at 2:42:19 PM, Paul Moore (p.f.mo...@gmail.com) wrote:
>>
>> [1] If I'm supposed to be getting notifications for comments on the PR
>> (as a member of the PyPA group, shouldn't I be?) then it
On 28 October 2015 at 20:15, Ralf Gommers wrote:
> It's the "Watch" button on the right top of
> https://github.com/pypa/interoperability-peps
Doh. Thanks.
Paul
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/list
On 29 October 2015 at 01:16, Nathaniel Smith wrote:
> Well I wouldn't say "no one". You weren't there at the NumPy BoF
> at SciPy this year, where a substantial portion of the room started
> calling for exactly this, and I felt pretty alone up front trying to
> squash it almost singlehandedly.
On 29 October 2015 at 19:23, Brett Cannon wrote:
>> I also don’t want to base any standard on setuptools entry points because
>> they are not a standard (and if we did, the key should not mention pip at
>> all, pip shouldn’t be special cased any more than setuptools should).
>
>
> Well, it kind of
(Hugely trimmed, because I coldn't find an easy way to pick out the
important bits of context, sorry!)
On 29 October 2015 at 23:23, Nathaniel Smith wrote:
> None of this affects correctness -- it's purely an optimization. But
> maybe it's an important optimization in certain specific cases.
One
On 30 October 2015 at 08:06, Marius Gedminas wrote:
> But code like this doesn't work! You build a wheel on Python 2.7, you
> get a twine-1.6.4-py2.py3-none-any.whl[*] in your pip wheel cache, and when
> you try to install it on Python 2.6, pip tries to use the same wheel,
> with install_requires
On 3 November 2015 at 16:25, Brett Cannon wrote:
> Thanks for writing the roadmap, Marcus! Heck of a lot easier to understand
> what is or is not sitting at a PEP at the moment.
Agreed. I'll have a proper read through it at some point and see if
there's anything I can add, but on a brief read it
On 4 November 2015 at 05:06, Marcus Smith wrote:
> I'm wary that trying to maintain "design principles" is too much for this
> document (at least more than I'd want to maintain).
That was my concern too. Let's wait & see how things play out.
> btw, I just added a sentence to the sdist section ab
On 5 November 2015 at 19:51, Thomas Güttler
wrote:
> My guess is that 99% of all new comers get confused by the current docs.
My guess (no more or less accurate than yours!) is that very few new
users read the docs. Maybe they get confused by the UI of the tools,
maybe not. But improving docs the
On 5 November 2015 at 20:40, Marcus Smith wrote:
>
> https://www.pypa.io/en/latest/history/
>
> maybe even funnier that we have a history page, but it's easy to forget all
> that's happened, so I made one awhile back...
Wow distutils was released in 2000, 15 years ago. I remember when it
happened
On 5 November 2015 at 21:08, Donald Stufft wrote:
> Thoughts?
The executable zip solution is in principle the best long-term
solution. But the breakage is major, and it pretty much permanently
cuts off any option to support use of pip as a library. That's
probably OK, but we need to understand th
On 5 November 2015 at 22:59, Donald Stufft wrote:
> I think we could integrate with py on Windows somehow so that we use the same
> lookup semantics as py does. I don't know enough about Windows and py.exe to
> know what exactly those are.
Hmm, I'm reluctant to get into complex interactions wit
On 6 November 2015 at 03:52, Glyph Lefkowitz wrote:
> If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current
> virtualenv, don't say anything; similarly if you invoke 'python -m pip' and
> 'which pip' matches. But if there's a mismatch, pip can print information
> in both cases.
On 6 November 2015 at 07:39, Ralf Gommers wrote:
> On Fri, Nov 6, 2015 at 12:37 AM, Donald Stufft wrote:
>>
>> If ``pip install —build … —no-clean …`` worked to do incremental builds,
>> would that satisfy this use case? (without the —upgrade and —no-deps,
>> —no-deps is only needed because —upgr
On 6 November 2015 at 12:10, Donald Stufft wrote:
> Doesn’t py.exe just look at some ini files and environment variables to
> decide what to invoke? I’m not sure why we couldn’t just replicate that
> behavior. Is there something that py.exe does that we can’t also do in Python?
What's there mig
On 6 November 2015 at 14:56, Tim Golden wrote:
>> One option would be to add a "py -which" mode that just does the
>> configuration lookup and then prints the path to the real python
>> executable. This would add the cost of one subprocess startup per pip,
>> but not 6?
>
> FWIW this will do that:
On 6 November 2015 at 14:33, Ines Barata wrote:
> Hello,
>
> I want to install the following version of pygame in my
> windows10.pro:install pygame-1.9.2a0-cp33-none-win_amd64.whl, but the file
> is in .whl format which I dont have any program to open it
> I checked the information in https://docs
201 - 300 of 1502 matches
Mail list logo
