[Distutils] Re: Question from a Beginner

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

[Distutils] FYI: PEP 632: Deprecate distutils module

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

[Distutils] Re: Twine 3.2.0 released

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

[Distutils] Re: package management - common storage while keeping the versions straight

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

[Distutils] Who is approving PyPI size limit exceptions these days?

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,

[Distutils] Re: pySerial 2.7 - MSI

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

[Distutils] Re: Python 3.7.4 MSI

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.

[Distutils] Re: API for Adding Contributors to a Package?

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: PEP-582 concerns

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

[Distutils] Re: sudo pip install: install pip files into /usr/local on Linux?

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

[Distutils] Re: Python 3.7 binary wheels

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

Re: [Distutils] Should abi3 tag be usable on Windows?

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

Re: [Distutils] Extracting distutils into setuptools

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

Re: [Distutils] Extracting distutils into setuptools

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

Re: [Distutils] A possible refactor/streamlining of PEP 517

is to 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

Re: [Distutils] A possible refactor/streamlining of PEP 517

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

Re: [Distutils] A possible refactor/streamlining of PEP 517

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

Re: [Distutils] A possible refactor/streamlining of PEP 517

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

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

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,

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

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

Re: [Distutils] python 3.6.1

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

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

On 20May2017 1315, Paul Moore wrote: On 20 May 2017 at 17:36, Steve Dower <steve.do...@python.org> 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

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

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 world

Re: [Distutils] PEP 517 - specifying build system in pyproject.toml

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

Re: [Distutils] GnuPG signatures on PyPI: why so few?

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

Re: [Distutils] GnuPG signatures on PyPI: why so few?

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.

Re: [Distutils] distlib and wheel metadata

On 23Feb2017 0914, Donald Stufft wrote: On Feb 23, 2017, at 11:04 AM, Nick Coghlan > 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

Re: [Distutils] Indexing modules in Python distributions

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

Re: [Distutils] RFC: PEP 541 - Package Index Name Retention

On 13Jan2017 1050, Lukasz Langa wrote: Thanks for review, Steve! On Jan 13, 2017, at 10:35 AM, Steve Dower <steve.do...@python.org> 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 lis

Re: [Distutils] Announcement: TLSv1.2 will become mandatory in thefuture

"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

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

"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

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

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

Re: [Distutils] 3.6.0b2 on windows

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

Re: [Distutils] Module Installation Issues

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

Re: [Distutils] Module Installation Issues

On 13Sep2016 1555, Donald Stufft wrote: On Sep 13, 2016, at 6:41 PM, Steve Dower <steve.do...@python.org> 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 user

Re: [Distutils] Module Installation Issues

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

Re: [Distutils] Module Installation Issues

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

Re: [Distutils] Module Installation Issues

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

Re: [Distutils] What is the official position on distutils?

"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

Re: [Distutils] Proposed new Distutils API for compiler flagdetection (Issue26689)

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

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

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

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

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

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

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]

Re: [Distutils] msvc9compiler.py - vcvarsall.bat is living onefolder higher - VS90COMNTOOLS

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,

Re: [Distutils] msvc9compiler.py - vcvarsall.bat is living one folder higher - VS90COMNTOOLS

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"

Re: [Distutils] setuptools 25.1.6 broke numpy.distutils on Windows

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

Re: [Distutils] cffi & Py_LIMITED_API

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

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

On 23Jul2016 1211, Donald Stufft wrote: On Jul 23, 2016, at 2:40 PM, Nicholas Chammas > wrote: I know a more concrete proposal would have to address a lot of details (e.g. like how to split contributions across multiple

Re: [Distutils] Outdated packages on pypi

Message- From: "Donald Stufft" <don...@stufft.io> Sent: ‎7/‎14/‎2016 17:25 To: "Steve Dower" <steve.do...@python.org> Cc: "Daniel D. Beck" <dan...@ddbeck.com>; "distutils-sig" <distutils-sig@python.org> Subject: Re: [Distutils] Outda

Re: [Distutils] Outdated packages on pypi

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" <don...@stufft.io> Sent: ‎7/‎14/‎2016 17:06 To: "Steve Dower" <steve.do...@python.o

Re: [Distutils] Outdated packages on pypi

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

Re: [Distutils] Outdated packages on pypi

On 13Jul2016 1456, Glyph Lefkowitz wrote: On Jul 13, 2016, at 1:54 PM, Steve Dower <steve.do...@python.org <mailto:steve.do...@python.org>> wrote: Possibly such user-contributed content would be valuable anyway https://alternativeto.net but for PyPI? :) Or just more gen

Re: [Distutils] Outdated packages on pypi

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

Re: [Distutils] PyPI index workaround

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

Re: [Distutils] wheel including files it shouldn't

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

Re: [Distutils] Parked Names in PyPI under user rodmena

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

Re: [Distutils] Parked Names in PyPI under user rodmena

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

Re: [Distutils] deprecating pip install --target

in my case I know there are no existing installs to worry about. Top-posted from my Windows Phone -Original Message- From: "Paul Moore" <p.f.mo...@gmail.com> Sent: ‎2/‎17/‎2016 2:10 To: "Robert Collins" <robe...@robertcollins.net> Cc: "Steve Dower&qu

Re: [Distutils] deprecating pip install --target

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

Re: [Distutils] command line versus python API for build systemabstraction (was Re: build system abstraction PEP)

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

Re: [Distutils] warning about potential problem for wheels

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

Re: [Distutils] warning about potential problem for wheels

. Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "Donald Stufft" <don...@stufft.io> Sent: ‎10/‎11/‎2015 7:31 To: "Steve Dower" <steve.do...@python.org> Cc: "distutils-sig" <distutils-sig@python.org>; "Laura Creighton

Re: [Distutils] warning about potential problem for wheels

ython.org" <Distutils-Sig@python.org> Subject: Re: [Distutils] warning about potential problem for wheels On Sun, 11 Oct 2015 17:44 Antoine Pitrou <solip...@pitrou.net> wrote: On Sun, 11 Oct 2015 08:07:30 -0700 Steve Dower <steve.do...@python.org> wrote: > > This does only

Re: [Distutils] Working toward Linux wheel support

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

Re: [Distutils] Add additional file categories for distutils, setuptools, wheel

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

Re: [Distutils] How to sign a exe created with bdist_wininst?

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

Re: [Distutils] Beyond wheels 1.0: helping downstream, FHS and more

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: [Distutils] setup_requires for dev environments

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

[Distutils] PYD/SO platform tags (#22980)

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

Re: [Distutils] PYD/SO platform tags (#22980)

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 + Steve Dower steve.do...@microsoft.com wrote: Hi distutils-sig, There's a bit of discussion going on at http

Re: [Distutils] PYD/SO platform tags (#22980)

Donald Stufft wrote: On Dec 12, 2014, at 6:23 PM, Steve Dower steve.do...@microsoft.com 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 opportunity to look into adding

Re: [Distutils] PYD/SO platform tags (#22980)

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've still specified the minor version in the tag

Re: [Distutils] windows overlay files

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 to

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

Ben Finney wrote: Steve Dower steve.do...@microsoft.com 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? It has been a long time since I

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

Claeysmailto:li...@janc.be Sent: ‎11/‎10/‎2014 17:33 To: distutils-sig@python.orgmailto: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-11-2014 om 16:35 [+]: * Forbidding

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

Ben Finney wrote: Paul Moore p.f.mo...@gmail.com 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

Re: [Distutils] Wheels and dependent third party dlls on windows

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

Re: [Distutils] Microsoft Visual C++ Compiler for Python 2.7

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 possible

Re: [Distutils] Wheels and dependent third party dlls on windows

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 package

Re: [Distutils] Microsoft Visual C++ Compiler for Python 2.7

AM, Steve Dower steve.do...@microsoft.commailto:steve.do...@microsoft.com wrote: 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

[Distutils] Microsoft Visual C++ Compiler for Python 2.7

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

Re: [Distutils] Building Python extensions on 64-bit Windows using the SDK compilers

Chris Barker wrote: On Wed, Sep 24, 2014 at 6:55 AM, Paul Moore p.f.mo...@gmail.com 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

Re: [Distutils] Building Python extensions on 64-bit Windows using the SDK compilers

We're very close to having some good news, but unfortunately, that's all I can say right now. Expect a more significant email/announcement from me in the next couple of weeks. (Distutils will hear it first and get the most detailed info.) Sent from my Windows Phone

Re: [Distutils] Create formal process for claiming 'abandoned' packages

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,

Re: [Distutils] Other ideas from today's packaging meetup at EuroPython

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 more

Re: [Distutils] pip, virtualenv, setuptools on Windows

Paul Moore wrote: On 7 July 2014 15:25, M.-A. Lemburg m...@egenix.com 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

Re: [Distutils] Windows 8 pkg_resources permissions bug

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 dive into that discussion again, go ahead and change the subject line :) ) Cheers, Steve Steve

Re: [Distutils] Windows 8 pkg_resources permissions bug

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

Re: [Distutils] ensurepip in Python 2.7

will likely also be the first one with Steve Dower at the helm for the creation of the Windows installers. Accordingly, I think it makes sense to leave proposing backporting ensurepip until 2.7.8 in November at the earliest. (Fortunately, there's no pyvenv in 2.7, so unbundling for the Linux distros

Re: [Distutils] Distribution and packaging mini-summit at PyCon: today 5 to 6

I'll be there too. Top-posted from my Windows Phone From: Daniel Holthmailto:dho...@gmail.com Sent: ‎4/‎11/‎2014 13:22 To: Éric Araujomailto:mer...@netwok.org Cc: DistUtils mailing list mailto:distutils-sig@python.org Subject: Re: [Distutils] Distribution and

Re: [Distutils] Distribution and packaging mini-summit at PyCon: today 5 to 6

I've also let the conda guys know, so we'll have someone from their team too (probably Travis). From: Steve Dowermailto:steve.do...@microsoft.com Sent: ‎4/‎11/‎2014 14:57 To: Daniel Holthmailto:dho...@gmail.com; Éric Araujomailto:mer...@netwok.org Cc: DistUtils

Re: [Distutils] distlib.mount API design (was: wheels on sys.path clarification (reboot))

FWIW, Windows (by default) has a regular maintenance task that will clean up old files in the TEMP directory. I think the default settings will delete files older than 30 days and more aggressively if disk space is running low. I'd say pick a consistent/static subfolder ('wheel_mount_35_amd64'

Re: [Distutils] Test Windows Installers

I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against: WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64 With Python 2.7.5, 3.2.3 and 3.3.2, x86 and x64 for each. (It helps to have a bit of practice with large test

Re: [Distutils] Test Windows Installers

Donald Stufft wrote: On Oct 3, 2013, at 5:59 PM, Steve Dower steve.do...@microsoft.com wrote: I've done basic testing (install, pip install, pip list, pip uninstall, repair, uninstall) against: WinXP SP3 x86 Vista SP2 x86/x64 Win7 SP1 x86/x64 Win8 RTM x86/x64 Win8.1 RTM x86/x64

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

Oscar Benjamin wrote: 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

  1   2   >