The main thing for you to do is to double-check all the names you type
in *before* you install anything. Most of the "security" issues come
down to people trying to catch misspellings ("typo-squatting"), so if
you've spelled everything correctly, you'll get the packages you expected.
If you do
Hi distutils-sig
Just wanted to let you know that I've proposed a core CPython PEP to
formally deprecate and remove the standard library distutils module.
Text and discussion at
https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134
The PEP has gone to python-dev formally beca
Congrats! And thanks for stepping up to maintain one of our important tools!
On 24Jun2020 1114, Brian Rutledge wrote:
https://pypi.org/project/twine/3.2.0/
Changelog: https://twine.readthedocs.io/en/latest/changelog.html
This is my first release as a Twine maintainer. Thanks to:
- Sumana Hari
On 24Jun2020 1923, David Mathog wrote:
I think I will experiment a little with pipenv and if necessary after
each package install use a script to remove the installed libraries
and replace them with a hard link to the one in the common area.
Maybe it will be possible to put in those links before
These issues seem to be awaiting approval:
https://github.com/pypa/pypi-support/labels/limit%20request
Most pressing (for me ;) ) is my colleagues at
https://github.com/pypa/pypi-support/issues/457, who are already dealing
with confused users not finding the packages they expect.
Thanks,
Ste
On 17Sep.2019 0255, Saqib Rashid (UK) wrote:
> We are testing team working on Smart Metering Implementation Programme
> and use pySerial 2.7. Our IT team is preparing an OS build with all the
> required tools in it. To silently install the tool they them in MSI. I
> was wondering if you have this i
While this is technically true, your chances of getting it to work are
very slim.
If you have a need for an MSI, my best suggestion right now is to take
one of our distributions (the package at
https://www.nuget.org/packages/python is likely easiest) and use a tool
to generate one from that.
On 07May2019 1048, Philip James wrote:
Hi there! I took a look at the API docs that I could find
(https://warehouse.readthedocs.io/api-reference/) and I couldn't see if
it was possible to programmatically edit the contributors who have
access to a project on PyPI.
My use case is for the BeeWa
On 20Feb2019 0927, Nathaniel Smith wrote:
That said, I prefer the approach of pipx
(https://pypi.org/project/pipx/) for scripts anyway. It too has the
problem of not updating your PATH for you, but at least it keeps tools
separate from dependencies, as they should be.
I think this is the third
On 20Feb2019 0831, Nathaniel Smith wrote:
Yeah, __pypackages__ has no way to handle scripts, and also no way to
access packages when you're running from a directory. Pipenv already
handles both of these cases fine today, so I'm not sure how having
__pypackages__ several years from now could hel
On 20Feb2019 0839, Paul Moore wrote:
On Wed, 20 Feb 2019 at 16:28, Steve Dower wrote:
To be totally clear, and maybe this needs to be in the PEP (probably in
three more various forms to make sure everyone gets it), you can emulate
most of the PEP today with "pip install --t
On 20Feb2019 0803, Dan Ryan wrote:
One final thing this enables as far as I understand is a sort of npm-like
option for ignoring resolution conflicts and simply performing a sort of nested
installation of subdependencies inside a top level dependency’s __pypackages__
folder. So if you did inst
On 20Feb.2019 0533, Tzu-ping Chung wrote:
> As one of the Pipenv maintainers, however, it is my personal opinion that this
> PEP would not be end up in the “yet another standard” situation, but even be
> beneficial to Pipenv, if done correctly.
>
> I hope this can provide some confidence :)
I'd l
On 20Feb.2019 0556, Nathaniel Smith wrote:
> I wonder if we should stick a header on the PEP draft saying something
> like this? There's a lot of scattershot responses happening and I think
> a lot of the people reacting are lacking context.
I agree, I think given the amount of attention it's gett
On 25May2018 0911, Victor Stinner wrote:
As an user, I want to use "sudo pip install" because packages
installed in /usr (or /usr/local) are accessible without having to
touch PYTHONPATH: the install directory is part of the default
sys.path.
Steve Dower also proposed the idea of
On 08May2018 2134, Nathaniel Smith wrote:
> for 3.6 there was a last minute problem
> with the Windows ABI that only got discovered during the rc period. But
> if you're willing to keep an ear out for that sort of thing, go wild.
I thought this was 3.5 (or maybe I've blanked out the more recent on
There is a solution to that problem on the linked issue. Basically, you need to
declare Py_LIMITED_API in your code or as an extra preprocessor variable.
Windows doesn’t use a filename suffix for python3.dll linked extensions as it
will be handled at load time. The tag for the wheel is outside o
It must, or it couldn’t have a build time dependency on distutils :)
Top-posted from my Windows phone
From: Donald Stufft
Sent: Saturday, September 30, 2017 18:15
To: xoviat
Cc: Steve Dower; DistUtils mailing list
Subject: Re: [Distutils] Extracting distutils into setuptools
I think that the
On 29Sep2017 1306, Donald Stufft wrote:
There are bits of distutils that are super useful (Steve indicated the
compiler support as one of them), and I think a better path forward is
to do like we’ve done with the packaging library. Make a compiler
package that can handle those bits and recommen
On 26Sep2017 1930, xoviat wrote:
This was a comment by @zooba (Steve Dower):
> (FWIW, I think it makes *much* more sense for setuptools to fix this
by simply forking all of distutils and never looking back. But since we
don't live in that world yet, it went into distutils.)
And he
avoid bugs being
reported in the wrong place, but at some point we need to trust the backend to
get it right even in a dirty source directory.
Top-posted from my Windows phone at EuroPython
From: Daniel Holth
Sent: Sunday, July 16, 2017 21:18
To: Steve Dower; Nathaniel Smith; Nick Coghlan
Cc
Just throwing in a vote, since I am following along – Nathaniel is totally
correct and I have no idea what Nick is talking about :)
In/out-of-place builds can’t guarantee that any “build wheel” operation will be
consistent with the “build sdist” operation, except for dealing with a very
narrow
One nice thing about providing a “put your work in this directory” setting for
all tasks is that only the front end has to know how and where to create it,
and how and when to clean it up later. Users may want to configure this across
all projects, regardless of the backend in use.
Permitting t
Big +1 for passing the option to the backend rather than making the frontend
figure out how to do each backend’s job for them.
And add MSBuild to the list, which trivially supports separate source,
intermediate and output directories, as well as incremental rebuilds. (And
recently got full x-pl
On 25May2017 0756, Paul Moore wrote:
On 25 May 2017 at 15:38, Nick Coghlan wrote:
So I'm inclined to accept the encoding amendment, and then
provisionally accept the overall PEP pending implementation in pip.
Me too. (Assuming I understand Steve's comments on backends, and he's
comfortable wi
On 22May2017 1253, Paul Moore wrote:
It seems to me there are 2 schools of thought:
1. There are likely to be fewer front ends than back ends, and so the
front end(s) (basically, pip) should deal with the problem. Also,
backends are more likely to be written by developers who are looking
at very
On 22May2017 0803, Paul Moore wrote:
On 22 May 2017 at 15:23, Nick Coghlan wrote:
No, that's discussed here:
https://www.python.org/dev/peps/pep-0517/#comparison-to-competing-proposals
Even though PEP 517 defines a Python API for build backends to
implement, it still expects installation tools
Hi Jost
For Windows, those commands are typically not available by default (on PATH)
because it is difficult to automatically add them.
You should be able to use “py.exe -m pip” as a substitute for “pip”. Or you can
modify your default PATH environment variable to include your Python directory
On 20May2017 1315, Paul Moore wrote:
On 20 May 2017 at 17:36, Steve Dower wrote:
In general, since most subprocesses (at least on Windows) do not have
customizable encodings, the tool that launches them needs to know what the
encoding is. Since we don't live in a Python 3.6 world quit
On 20May2017 1011, Thomas Kluyver wrote:
On Sat, May 20, 2017, at 05:36 PM, Steve Dower wrote:
In general, since most subprocesses (at least on Windows) do not have
customizable encodings, the tool that launches them needs to know what
the encoding is. Since we don't live in a Python 3.6
On 20May2017 0820, Nick Coghlan wrote:
Good point regarding the fact that the Windows 16-bit APIs only come
into play for interactive sessions (even in 3.6+), while for PEP 517
we're specifically interested in the 8-bit pipes used to communicate
with build subprocesses launched by an installation
Another drive-by contribution: what if twine printed the hashes for anything it
uploads with a message basically saying "here are the things you should publish
somewhere for this release so people can check the validity of your packages
after they download them"?
I suspect many publishers have
FWIW, I dropped a portable version into the windows-installer externals that
are pulled down by the release scripts (from svn.p.o). It does require me to
import my key on new machines, but since I don't use it for anything but
re-signing the releases it's worth it to avoid all the intrusions.
S
On 23Feb2017 0914, Donald Stufft wrote:
On Feb 23, 2017, at 11:04 AM, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
Redistributors may *ask* a publisher to reclassify their project as a
library or a devtool (and hence also avoid pinning their dependencies
in order to make integration easier)
I'm interested, and potentially in a position to provide funded infrastructure
for this (though perhaps not as soon as you'd like, since things can move
slowly at my end).
My personal preference would be to download a full list. This is slow moving
data that will gzip nicely, and my uses (in ID
Yep, this is what I chose to do for our packages like
https://pypi.org/project/microsoft/ (updated since I first posted about it).
The intent of this PEP is to be able to clean up *unmaintained* packages, so if
you have an "invalid" package but also a justification and you are reachable, I
expe
On 13Jan2017 1050, Lukasz Langa wrote:
Thanks for review, Steve!
On Jan 13, 2017, at 10:35 AM, Steve Dower wrote:
An *abandoned* project can be transferred to a new owner for purposes
of reusing the name when ALL of the following are met:
...
The list here is nearly identical to the
Looks great to me. Just a few comments that may help reduce the burden
on the index maintainers.
On 13Jan2017 1008, Lukasz Langa wrote:
In every case where contacting the user is necessary,
the maintainers will try to do so at least three times, using the
following means of contact:
* the e-ma
"I don’t think it’s a particularly big deal to tie the tls module to the Python
lifecycle though"
I'd hope that the API of this module is stable enough and the native part of
the implementation is OS-specific enough that we may not even need to update it
that often. (I'm advocating very strongl
"Alternatively, I've recently started using Visual Studio Code as my editor for
work ..."
FWIW, the long-term Python story in VSCode is currently (largely) one of my
responsibilities, and that bootstrapping flow is exactly one of the pieces I
really want to put in. Unfortunately, nobody has let
The "curated package sets" on PyPI idea sounds a bit like Steam's curator
lists, which I like to think of as Twitter for game reviews. You can follow a
curator to see their comments on particular games, and the most popular
curators have their comments appear on the actual listings too.
Might b
On 12Oct2016 0418, Robin Becker wrote:
I have a question regarding an error message I see when building an
extension for windows using the 3.6.0b2 release
C:\ux\XB33\py36_x86\lib\site-packages\wheel\pep425tags.py:77:
RuntimeWarning: Config variable 'Py_DEBUG' is unset, Pytho
n ABI tag may be
On 13Sep2016 1559, Matthew Brett wrote:
Perhaps a better idea would be to add some smarts to the REPL (but not to
Python itself) that would detect something like:
pip install
And print a better error message that gives a better indication about what’s
gone wrong besides a SyntaxError?
I w
On 13Sep2016 1555, Donald Stufft wrote:
On Sep 13, 2016, at 6:41 PM, Steve Dower wrote:
I think it's one of these things where we should suck it up and let the 90%
case work fine, then display a big fat warning if anything weird may have
happened and let users sort it out themselves.
On 13Sep2016 1500, Paul Moore wrote:
On 13 September 2016 at 21:12, Thomas Kluyver wrote:
One thing I'd quite like to see Python grow is a standard function to
install packages from inside Python.
That's not too hard in principle - pip.main(['install', package]) is
basically all you'd need (m
On 13Sep2016 1312, Thomas Kluyver wrote:
On Tue, Sep 13, 2016, at 08:39 PM, Steve Dower wrote:
It would help if you could post the full error output (sanitizing
paths if needed). But you may just need to upgrade pip (python -m
install -U pip).
I think Ryan may have typed that command at a
It would help if you could post the full error output (sanitizing paths if
needed). But you may just need to upgrade pip (python -m install -U pip).
Knowing exactly where the syntax error is coming from will help us figure out
which package has the problem. There are at least three involved here
"add it to setuptools first, and then add things to distutils where we feel
they're sufficiently stable to not need the benefit of the faster setuptools
update cycle"
I nominate this as the official policy on API changes for distutils, with
regular maintenance mode policies applying to anything
Some of the core development team will be sprinting full time for the week
leading up to beta 1, so expect a lot of things to get added then.
My main concern with this is compatibility rather than the interface, but as a
new feature I think it's best to be only in setuptools. Distutils is minima
On 23Aug2016 0937, Brett Cannon wrote:
I should also mention I have never come across anyone at Microsoft use
the bdist_msi or bdist_winst installers (I've added Steve to this email
in case my experience is wrong).
In large part this is because I've gotten to them first :)
Personally I don't l
We could also extend the py.exe launcher to resolve a matching Python install
for a wheel and run pip to install it. Then double-clicking a wheel file would
do something useful.
Having a standard UI would be better, though non-trivial.
Top-posted from my Windows Phone
-Original Message
Do you mean like zipapp and *.pyz files?
Top-posted from my Windows Phone
-Original Message-
From: "Nick Coghlan"
Sent: 8/16/2016 22:42
To: "Leonardo Rochael Almeida"
Cc: "distutils sig"
Subject: Re: [Distutils] Deprecating little used file types/extensions onPyPI?
On 17 August 201
There may be a bug in setuptools. We've already seen one reported and fixed in
the last week, so possibly this is related.
Issues in setuptools go to their github page (don't have the link handy on my
phone). Nothing has changed in distutils in over a year here and it's been
working just fine,
On 09Aug2016 1519, Dr. Andreas Krueger wrote:
I could not find a github repo, otherwise I would have filed this as an
"issue" there.
The subfolder "VC" is wrong in msvc9compiler.py
- at least on my system (win7-64bit, py2.7.12, anaconda 2.4.1, conda 4.1.11)
So in your "msvc9compiler.py"
ins
On 09Aug2016 0213, Antoine Pitrou wrote:
Just a heads-up that latest setuptools is incompatible with
numpy.distutils on Windows:
https://github.com/pypa/setuptools/issues/728
For those who don't want to dig into the issues and pull requests, it
seems that multiple libraries were patching diffe
On 01Aug2016 0702, Nick Coghlan wrote:
On 1 August 2016 at 23:36, Daniel Holth wrote:
build_ext command determines
the DLL extension. It could be patched or modified to read an "I'm ABI3"
flag on the Extension() object.
We could pass an ABI3 flag to bdist_wheel in the same way we ask for
unive
On 23Jul2016 1211, Donald Stufft wrote:
On Jul 23, 2016, at 2:40 PM, Nicholas Chammas
mailto:nicholas.cham...@gmail.com>> wrote:
I know a more concrete proposal would have to address a lot of details
(e.g. like how to split contributions across multiple maintainers),
and perhaps there is no wa
--Original Message-
From: "Donald Stufft"
Sent: 7/14/2016 17:25
To: "Steve Dower"
Cc: "Daniel D. Beck" ; "distutils-sig"
Subject: Re: [Distutils] Outdated packages on pypi
On Jul 14, 2016, at 8:19 PM, Steve Dower wrote:
I'm still keen to find
people to useful forks or alternative
packages that doesn't require thousands of mentions at conferences for all time
ala PIL.
Top-posted from my Windows Phone
-Original Message-
From: "Donald Stufft"
Sent: 7/14/2016 17:06
To: "Steve Dower"
Cc: "Daniel D. Beck
On 14Jul2016 0619, Daniel D. Beck wrote:
Free-form, user-generated content on PyPI would become a pathway for
harassment and abuse. Introducing user-generated content on PyPI would
necessarily put an emotional burden on package maintainers in addition
to the maintenance burden (unless PyPI modera
On 13Jul2016 1456, Glyph Lefkowitz wrote:
On Jul 13, 2016, at 1:54 PM, Steve Dower mailto:steve.do...@python.org>> wrote:
Possibly such user-contributed content would be valuable anyway
https://alternativeto.net but for PyPI? :)
Or just more general reviews/warnings/info. "D
On 13Jul2016 1252, Glyph Lefkowitz wrote:
The primary thing would be to have a banner on the page and a warning
from `pip install´. Those of us close to the heart of the Python
community already have various ways of reading the tea leaves to know
that things are likely to be unmaintained or bitr
I'm also interested (for the same support in Visual Studio) though we're
unaffected by this change.
A batch API to get info for many packages would be great. Currently we scrape
simple and then post JSON queries for individual packages.
Cheers,
Steve
Top-posted from my Windows Phone
-Orig
On 27Apr2016 1445, Paul Moore wrote:
Personally, I agree with Donald that the "normal" process of building
a distribution should be:
1. Build the sdist.
2. Build wheels *from* that sdist.
3. Check the built sdist and wheels.
4. Upload the files once you've confirmed they are OK.
The tools shoul
Thanks for the vouch, we are indeed both current Microsoft employees. I stopped
using my work email for Python stuff when our server started corrupting URLs to
add a phishing/malware filter.
Feel free to email the pyt...@microsoft.com address attached to the Microsoft
user and I'll reply to you
Also the "windows" package.
Might just want to release all of those package names, as he's clearly a troll,
but in light of the other discussions I think a case of well established and
enforceable trademarks should be straightforward.
(Don't honestly know what we'd _do_ with packages with those
and in my case I know there are no
existing installs to worry about.
Top-posted from my Windows Phone
-Original Message-
From: "Paul Moore"
Sent: 2/17/2016 2:10
To: "Robert Collins"
Cc: "Steve Dower" ; "Python Distutils SIG"
Subject:
I was also planning to use it in an upcoming project that has to "do its own"
package management. The aim was to install different versions of packages in
different directories and use sys.path modifications to resolve them at runtime
(kind of like what setuptools did in the older days).
An alt
As much as I dislike sniping into threads like this, my gut feeling is strongly
pushing towards defining the Python interface in the PEP and keeping command
line interfaces as private.
I don't have any new evidence, but pickle and binary stdio (not to mention
TCP/HTTP for doing things remotely)
ing 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
about which one to use though.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From: "Donald Stufft"
Sent: 10/11/2015 7:31
To: "Steve Dower"
Cc: "distutils-sig" ; "Laura Creighton"
Subject: Re: [Distutils] warning about potentia
An extra data point is that we've had exactly one report of Python 3.5 not
working due to lack of SSE, and that person was also on Windows XP (so zero
reports on supported platforms).
That said, I should probably just fix 3.5.1 to not use SSE for core or
distutils builds. I doubt there was a hu
I've written up a long technical blog post about the compiler and CRT
changes in Python 3.5, which will be of interest to those who build and
distribute native extensions for Windows.
http://stevedower.id.au/blog/building-for-python-3-5/
Hopefully it puts some of the changes we've made into a
On 14Aug2015 0038, Nathaniel Smith wrote:
Windows and OS X don't (reliably) have any package manager. So PyPI
*is* inevitably going to contain non-Python shared libraries or
statically linked modules or something like that. (And in fact it
already contains such things today.) I'm not sure what th
My brief POV is that if a package on Windows is installing anything outside
sys.path at all then it's an application and should use something other than
wheel for installation. WiX/MSI will do proper reference counting and upgrades
to avoid having multiple versions colliding with each other (ima
It may be possible to add an empty key container to the stub with signtool so
that it can be filled in after adding the zip without having to extend the
length. I believe the PE header is modified to locate the certificate, so it
doesn't necessarily have to be at the end.
Feel free to investiga
On the Start Menu suggestion, I think that's a horrible idea. Pip is not the
system package manager and it shouldn't be changing the system. Unversioned
script launchers are in the same category, but aren't quite as offensive.
I know it's only a hypothetical, but I'd much rather it didn't get re
Donald Stufft wrote:
> So yea, what's the actual problem that this is attempting to solve?
ISTM (whether this is the actual intent or not) that this would be handy to
differentiate between the dependencies needed when installing from a wheel vs.
an sdist. Daniel's example of setup_requires inclu
Steve Dower wrote:
> Antoine Pitrou wrote:
>
> My legalistic rationale for using cp3 is that it's actually the version tag,
> not
> the ABI tag. It seemed from my reading that you'd get tags like
> "cp35-abi3-win32", which is not helpful because you'v
> Donald Stufft wrote:
>> On Dec 12, 2014, at 6:23 PM, Steve Dower wrote:
>>
>> Hi distutils-sig,
>>
>> There's a bit of discussion going on at http://bugs.python.org/issue22980
>> about extending SO tags to include bitness values, and I took the
&g
Antoine Pitrou wrote:
> Sent: Friday, December 12, 2014 1551
> To: Distutils-Sig@Python.Org
> Subject: Re: [Distutils] PYD/SO platform tags (#22980)
>
> On Fri, 12 Dec 2014 23:23:03 +0000
> Steve Dower wrote:
>
>> Hi distutils-sig,
>>
>> There
Hi distutils-sig,
There's a bit of discussion going on at http://bugs.python.org/issue22980 about
extending SO tags to include bitness values, and I took the opportunity to look
into adding platform tags for .pyd files on Windows.
There's a patch up there, but I'm interested in any thoughts or
Robin Becker wrote:
> Hi,
> I hope some windows expert can assist me with a production problem. We
> support a
> user using windows who reports problems concerning missing attributes. Using
> GotoMeeting we inspected the file together and see that the attribute should
> be
> present. I asked them
: Jan Claeys<mailto:li...@janc.be>
Sent: 11/10/2014 17:33
To: distutils-sig@python.org<mailto:distutils-sig@python.org>
Subject: Re: [Distutils] Call for information - What assumptions can I make
about Unix users' access to Windows?
Steve Dower schreef op ma 10-1
Ben Finney wrote:
> Steve Dower writes:
>> Ben Finney wrote:
>> > The restrictions of the license terms make MS Windows an
>> > unacceptable risk on any machine I'm responsible for.
>>
>> Just out of interest, which restrictions would those be?
>
Ben Finney wrote:
> Paul Moore writes:
>
>> To that end, I'd like to get an idea of what sort of access to Windows
>> a typical Unix developer would have. […] Ideally, a clean Windows 7 or
>> later virtual machine is the best environment, but I don't know if
>> it's reasonable to assume that.
>
David Genest wrote:
> 1) add the dependent dlls to every package that needs it (Steve's answer
> https://mail.python.org/pipermail/distutils-sig/2014-September/024982.html
> concurs that the dependent dll would be loaded only once)
This is the best approach regardless of what else works/doesn't wo
David Genest wrote:
> Subject: Re: [Distutils] Wheels and dependent third party dlls on windows
>
>
>> This is not true. Python loads DLLs with
>> LOAD_WITH_ALTERED_SEARCH_PATH, to allow them to be located alongside the pyd
> file. You should therefore be able to ship the dependent dll in the pac
Paul Moore wrote:
> On 30 September 2014 16:56, Olivier Grisel wrote:
>> What is the story for project maintainers who want to also support
>> Python 3.3+ (for 32 bit and 64 bit python) for their project with
>> binary wheels for windows?
>
> It would be so easy at this point to ask "What's the
Olivier Grisel wrote:
> Thank you very Steve for pushing that installer out, this is very appreciated.
>
> What is the story for project maintainers who want to also support Python 3.3+
> (for 32 bit and 64 bit python) for their project with binary wheels for
> windows?
> At the moment it's possi
p-posted from my Windows Phone
From: Piotr Dobrogost<mailto:p...@2014.dobrogost.net>
Sent: 9/27/2014 3:34
To: Steve Dower<mailto:steve.do...@microsoft.com>
Cc: distutils sig<mailto:distutils-sig@python.org>
Subject: Re: [Distutils] Microsoft Visu
I'll post this on the various other lists later, but I promised distutils-sig
first taste, especially since the discussion has been raging for a few days (if
you're following the setuptools repo, you may already know, but let me take the
podium for a few minutes anyway :) )
Microsoft has releas
Chris Barker wrote:
> On Wed, Sep 24, 2014 at 6:55 AM, Paul Moore wrote:
>> Thanks for the pointer. (Also thanks to Allen Riddell). I'll take a
>> look. Ideally, what I'd like to do is write something up to help
>> non-Windows experts get things up and running, so this will be very
>> useful.
>
>
dows Phone
From: Paul Moore<mailto:p.f.mo...@gmail.com>
Sent: 9/23/2014 15:42
To: Distutils<mailto:distutils-sig@python.org>; Steve
Dower<mailto:steve.do...@microsoft.com>
Subject: Building Python extensions on 64-bit Windows using the SDK compilers
Can anyone give me some
Donald Stufft wrote:
> Perhaps in Warehouse the procedure can be automated to some degree
> and a public record of what actions were taken and when? I don’t mean like
> a public log of the actual email address or email content or anything of the
> sort. Just like a "attempted to contact on X date"
"Will that also allow me to put ‘macports’ or ‘homebrew’ in there you can
create an Cython-0.20.1-cp27-none-lmacosx_x86_64-macports_10.10.whl
distribution?"
Just how many wheels are people going to have to publish? Who has that many dev
machines? Without a build farm, I can't see this being mor
Paul Moore wrote:
> On 7 July 2014 15:25, M.-A. Lemburg wrote:
>> Yes: Installers for Python 2.6, 2.7 and 3.3 :-)
>
> Ha. That one, I'll leave to someone who cares about 2.x... ;-)
>
> Paul
That "someone" is Nick Coghlan, and as long as the python-dev discussion
doesn't take too long, it should
rent CPython installers support this sort of install if you change the
directory, but maybe it is time for pip/setuptools to start assuming that user
site-packages is the default on Windows so we could actually consider changing
the default Python install location? (If anyone really wants to div
My guess would be that something is setting permissions for the current user,
and these installs were done by an admin user who is not the current user. This
will result in explicit permissions on the file that may deny read access.
I'll have to confirm tomorrow. Do you have the exact versions o
And just as I post that, I figure it out. Guess I will be doing the next build.
Cheers,
Steve
Top-posted from my Windows Phone
From: Steve Dower<mailto:steve.do...@microsoft.com>
Sent: 5/3/2014 7:48
To: Nick Coghlan<mailto:ncogh...@gmail.com>
1 - 100 of 123 matches
Mail list logo
