[Distutils] Re: Is ensurepip still a thing?

> IIRC, ensurepip by design doesn't go to the internet , so it will only > ever upgrade to the version bundled with Python Now I’m really confused — if pip is already bundled with Python, then what is ensurepip for ?!?! Or really, the question at hand: should a user starting from scratch with a p

[Distutils] Re: Packaging Advice for EFF's Certbot

I agree that you are probably best off integrating with the system packaging system in this case. But if you do want to deploy and app with all its dependencies in a controlled environment, conda constructor May make that easy: https://github.com/conda/constructor -CHB Sent from my iPhone On

[Distutils] Or in version spec...

Sorry to lose the thread — lousy iPhone mail app... Conda supports or in its meta.yaml format: https://conda.io/docs/user-guide/tasks/build-packages/package-spec.html#build-version-spec Maybe look to that for prior art? And it would be mildly less confusing to have consistency between the syste

Re: [Distutils] Outstanding questions for PEP 541: Package Index Name Retention

> I don’t know how much we can or should define “being used”. For instance, every package in existence is going to be downloaded via mirroring, so we can’t go by pure download counts (and some mirrors just use pip to do their downloading) and we’re going to need to interpret the download counts to

Re: [Distutils] [proposal] shared distribution installations

, the behaviour i aim for would be moslty like virtualenv but without the file duplication. For what it’s worth, conda environments use hard links where possible, so limiting duplication... Maybe conda would solve your problem... -CHB I beleive nix could also benefit from parts of such a

Re: [Distutils] Extracting distutils into setuptools

distutils works fine for its original purpose (building components for the system Python in Linux distros), What does Linux have to with it? In the eagle days, I found it most helpful for Windows, actually. And it's very helpful for OS-X as well. It was also great for pure python bundli

Re: [Distutils] Accepting PEP 541?

This looks great: thanks for moving it along! Minor notes (all copy editing): It could use some editing to bring it into the present: """ Existing package repositories such as CPAN [3] , NPM [4] , an

Re: [Distutils] PEP 517 again

One thing to keep in mind is that there are quite a few projects on pypa with pure python source distributions uploaded that will not be updated and people may still desire to use. We want pip to be able to still build and install them. That is the challenge! But the motivating use case here was

Re: [Distutils] PEP 517 again

> that neither pip nor the setuptools backend should not change the tags > it applies to wheels by default). I'm a bit confused -- are we talking about the backwards compatible path to the future -- or the end-game? In short -- I'm sure we'll have to do some hacky stuff to keep backwards compatib

Re: [Distutils] Distuils MSVC link failure between libraries

I'm trying to create multiple C++ extensions that have dependencies between them. This works fine on Linux with gcc, but I get link failures on Windows with MSVC due to this Is that the only issue? MSVC and FCC l

Re: [Distutils] Which commercial vendor?

> On Mar 30, 2017, at 1:53 AM, Thomas Güttler > wrote: > > > My frustration has reached a limit. Yes, I am willing to pay money. > > Which vendor do you suggest to give me a reliable package management? You may want conda -- it's an open source project, and you can get commercial support through

Re: [Distutils] install questions and help requested. ---pyautogui

This is really a list for discussing development of distribution tools, rather than help on basic usage. But; > > >>> pip install pyautogui > SyntaxError: invalid syntax This looks like you are trying to run pip at the Python prompt. Pip is designed to be run st a system command line ("DOS promp

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

> > > I think it's unfair to describe these efforts as a "kludge"; I was specifically referring to using wheels to deliver C libs-- pip+wheel were not designed for that. But I don't mean to offend, there has been a lot of great work done, and yes, the situation has much improved as a result. Ther

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

> > If we're going through all this trouble, isn't it better just to jump to .zip > files like every other distribution format in existence? Yes. :-) -CHB ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/

Re: [Distutils] What role to eggs still play?

Thanks, I think I'm getting it. About the toml file... the *-info metadata is a compiled artifact, according to all the existing Python packages. Most sdists even have a *.egg-info directory. If it's a compiled artifact, then shouldn't it NOT be in a source dist? It is inconvenient if you want

Re: [Distutils] Outdated packages on pypi

Getting to this thread late, but it didn't seem that was resolved in the least, so I'll as my $0.02 > That overall got me thinking about namespace pollution in pip, that > once something is pushed in, it's like to stay there forever. This REALLY is a problem, and one that will only get worse. It

Re: [Distutils] comparison of configuration languages

​Not asking for any change but has anyone looked at libconfig ? ​It looks quite interesting: simple grammar and nesting support. What do you think of it As pointed out, it's a C lib. But as we all like writing tools, it wouldn't be very h

Re: [Distutils] PEP for specifying build dependencies

> When the upstream installation process is instead broken up into > "build a binary artifact" and "install a binary artifact", that brings > a few benefits: Great -- thanks for the detailed explanation. Sounds like a good plan, then. -CHB ___ Distutils

Re: [Distutils] Name arbitration on PyPI

Another high profile example of such a project: PIL. Was PIL ever on PyPi? Anyway, yup, the solution there was to fork give it s new name -- Pillow was born. CHB 19.04.2016, 00:56, Chris Barker kirjoitti: On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco wrote: > >> 1.� PyYAML is a package th

Re: [Distutils] The mypy package

> Though I do wonder how effective that would be in this case. For all we > know, in the case of mypy, the maintainer is simply ignoring someone else who > is trying to take the name they registered. (I get emails all the time for > people trying to get me to sign over my domain names; Domain

Re: [Distutils] What's up with PyPi maintenance?

b) Is there a serious lack of folks available to address such issues? > This is the correct answer. I can't even keep on top of the request from people wanting to take over packages. if (b), should we make a concerted effort to recruit new folks to assist > PyPi maintenance / development??? > T

Re: [Distutils] How to get pip to really, really, I mean it -- rebuild this damn package!

>> Requirement already satisfied (use --upgrade to upgrade): gsw==3.0.3 from >> file:///Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3 in >> /Users/chris.barker/miniconda2/conda-bld/work/gsw-3.0.3 > > I think this is saying that pip thinks it has found an > already-installed version of gsw

Re: [Distutils] draft PEP: manylinux1

(e.g. by bumping up >> the base ABI from CentOS 5 to CentOS 6). > > The problem with this is that python 2.7 is going to be supported and > widely used until well past the EOL of CentOS 5, and maybe even past > the EOL of CentOS 6 Given that we're starting now ( not a year or two ago) and it'll ta

Re: [Distutils] draft PEP: manylinux1

I went through this list and compiled manylinux1 wheels for each of the top 15 projects in the list (py35). The wheels are here, if you're interested http://stanford.edu/~rmcgibbo/wheelhouse Cool! Are the non-manylinux dependencies all statically linked? -CHB ___

Re: [Distutils] draft PEP: manylinux1

> So without a plan to provide all that stuff -- I"m not sure of the utility > of this -- how are you gong to get PIL/Pillow to work? statically link up > the ying-yang? Not sure the linux world will take to that. > We can explain how things work in details for some packages, but the main rational

Re: [Distutils] Installing packages using pip

How it works in the terminal is less important to me than how it works in IDLE though; being able to teach how to use Python through IDLE (deferring discussion of terminals etc) is useful for introductory programming classes. Personally, I don't use IDLE for teaching, but do use iPython. But if we

Re: [Distutils] The future of invoking pip

> If we waved our hands and were able to magically make Python package > management perfect, what would that look like? well, I think the command would be: python install package_name I know there are good reasons to keep package installer development out of core, but if have ensurepip-- we cou

Re: [Distutils] The future of invoking pip

> In this situation, if pip's default for finding the python environment > were to search the path for 'python' instead of using sys.executable, One trick here -- PATH may not be the same everywhere. For instance, on OS-X, the environment GUI programs get is entirely independent of the shell. So,

Re: [Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

> While I understand what you're trying to achieve (and I'm in favour, > in general) it should be remembered that pip's core goal is installing > packages - not being a component of a development workflow. Yes -- clear separation of concerns here! So what IS supposed to be used in the development

Re: [Distutils] Platform tags for OS X binary wheels

On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote: I'm using the Python from the Miniconda installer with py35 released last week. Then you should not expect it to be able to find compatible binary wheels on PyPi. Pretty much the entire point of conda is to support Numpy and friends. It's actu

Re: [Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

>> I'm not talking about in place installs, I'm talking about e.g. building a >> wheel and then tweaking one file and rebuilding -- traditionally build >> systems go to some effort to keep track of intermediate artifacts and reuse >> them across builds when possible, but if you always copy the sour

Re: [Distutils] warning about potential problem for wheels

But even if so do we WANT to now be supporting 4 Windows platforms? win32 win32_sse2 win64 win64_sse2 and then, what about sse3, etc??? Longer term, more platforms (particularly more platforms that really only differ by some compiler flags) shouldn’t be a very big deal, because my dream for PyPI

Re: [Distutils] README.rst vs DESCRIPTION.rst

Sent from my iPhone On Sep 27, 2015, at 11:19 AM, Ionel Cristian Mărieș wrote: On Sun, Sep 27, 2015 at 8:05 PM, Thomas Güttler ​I don't think there can be a "definitive guide line"​. Unlike the core language the packaging part of Python is a messy soup of different and often competing ideas, s

Re: [Distutils] Working toward Linux wheel support

> On Jul 17, 2015, at 1:19 PM, Daniel Holth wrote: > > I've recently packaged SDL2 for Windows as a wheel, without any Python code. > It is a conditional dependency "if Windows" for a SDL wrapper. Cool, though I still think we need wheel-level deps -- the dependency is on the particular binary,

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

Maybe I wasn't very clear -- I was addressing what conda might provide in the context of using conda packages with pip/pipy. A conda environment provides a great deal more, yes. system-site-packages may very well be for a different version of the python interpreter and stdlib. Isn't that handled

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

For the most part, I think it's all been said. What should and shouldn't be installed by default is really specific extension dependent, not much point in speculating. But a comment or two: having to type > "python -m something" rather than just "something" isn't broken, it's > just an inconve

Re: [Distutils] setup_requires for dev environments

Folks, I'm having a hard time catching up with this, but maybe a few comments from someone well outside the trenches will be helpful. And note that one of use cases I'm now wrestling with is using another package manager (conda), and setuptools is currently a PITA in that context. >> you that "p

Re: [Distutils] wheels or system packages for pip on ubuntu

Your might want to consider conda and conda environments for this. http://www.continuum.io/blog/conda It provides a single packaging solution for both python and dependencies. And there are probably already recipes for everything you need. -Chris > On Sep 3, 2014, at 3:24 AM, Reinout van Rees

Re: [Distutils] Handling the binary dependency management problem

On Dec 5, 2013, at 1:12 PM, Oscar Benjamin wrote: > > Yes, I wouldn't want that kind of bad PR getting around about > scientific Python "Python is slower than Matlab" etc. > Well, is that better or worse that 2% or less people finding they can't run it on their old machines > It seems as if

Re: [Distutils] Handling the binary dependency management problem

On Dec 4, 2013, at 11:35 PM, Ralf Gommers wrote I'm just wondering how much we are making this hard for very little return. I also don't know. I wonder if a poll on the relevant lists would be helpful... I'll start playing with wheels in the near future. Great! Thanks! There are multip

Re: [Distutils] Handling the binary dependency management problem

On Dec 5, 2013, at 1:40 AM, Paul Moore wrote: > > I'm not sure how this would work - wheels don't seem to me to be > appropriate for installing "external dependencies", but as I'm not > 100% clear on what you mean by that term One of the key features of conda is that it is not specifically tied

Re: [Distutils] Handling the binary dependency management problem

Ralf, Great to have you on this thread! Note: supporting "variants" on one way or another is a great idea, but for right now, maybe we can get pretty far without it. There are options for "serious" scipy users that need optimum performance, and newbies that want the full stack. So our primary a

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

On Nov 1, 2013, at 11:25 PM, Marcus Smith wrote: > > pip does confirm the wheel file is compatible with your platform/python > (based on the file tags), when downloading from indexes and links. > BUT, just noticed, when installing directly from a specific file, it seems > it's not checking, so I

Re: [Distutils] Comments on PEP 426

someone wrote: > even though plain distutils would work just fine for a very > large subset of packages. Most of my own packages > only use setuptools for its dependency resolution, and > that's for the most part provided by pip in the future. Another comment from the peanut gallery: This is ve

Re: [Distutils] Multi-version import support for wheel files

PJE: Thanks for the clarification: based on that: +1 on Nick's proposal. Chris On Aug 26, 2013, at 1:41 PM, PJ Eby wrote: > On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft wrote: >> There is always a cost. In this case mostly in complexity and start up time. >> >> As you mentioned originally

Re: [Distutils] Multi-version import support for wheel files

Just to add a bit more "FUD" ;-) I do a lot of packaging things up with py2app, py2exe, etc. -- I find I often want to be able to give folks "one thing" that they can install and run, and I'd rather they don't even need to know it's built with python. A while back, when I was doing this with a w

Re: [Distutils] Multi-version import support for wheel files

On Sun, Aug 25, 2013 at 12:06 AM, Nick Coghlan wrote: > anyone that is > currently doing side-by-side multi-versioning in Python is using the > pkg_resources API to do it, since that's the only option currently > available. I'm not sure it changes anything, but there are other options - ones spec

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

On Thu, Aug 22, 2013 at 8:17 PM, Nick Coghlan wrote: > numpy-1.7.1-cp27-cp22m-win32.whl > numpy-1.7.1-cp27-cp22m-win32-sse.whl > numpy-1.7.1-cp27-cp22m-win32-sse2.whl > numpy-1.7.1-cp27-cp22m-win32-sse3.whl I'm still confused -- how would "pip install numpy" know which of these to install? -Chr

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

On Thu, Aug 22, 2013 at 3:52 PM, Paul Moore wrote: > On 22 August 2013 23:08, Chris Barker - NOAA Federal > My impression is that the architecture and "fat binary" stuff on OSX is the > bit that may bite you. exactly. > I know little or nothing about OSX, but I'm s

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

On Thu, Aug 22, 2013 at 9:37 AM, Paul Moore wrote: > That is essentially possible now. > > 1. Go to Christoph Gohlke's website and download his bdist_wininst > installers for numpy and scipy. Exactly. And when all this settles down, hopefully Christoph, and others, will put up binary wheel

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

> C extensions are not ready for use yet anywhere other than on Windows > (Linux in particular has architecture/ABI questions to resolve).. > Projects that use script wrappers probably shouldn't expect wheels to > manage these seamlessly yet (things are still in flux in that area). > "Advanced" fea

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

And sent form Paul Moore -- accidentally got off-list (my fault): On 22 August 2013 18:47, Chris Barker - NOAA Federal wrote: > I'm still confused as to the state of all this -- are the tools ready > for projects to start posting wheels so that pip can find them? Basically, the answe

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

On Thu, Aug 22, 2013 at 6:52 AM, Oscar Benjamin wrote: > I'm pretty sure the current Windows installer just doesn't bother with > BLAS/LAPACK libraries. Maybe it will become possible to expose them > via a separate wheel-distributed PyPI name one day. Well, the rule of thumb with Windows binarie

Re: [Distutils] distutils.util.get_platform() - Linux vs Windows

On Mon, Aug 19, 2013 at 11:15 PM, wrote: > What does your 'uname -m' return? x86_64 > Is it possible you're really running a 32-bit > Python on a *32-bit* OS X kernel? [http://superuser.com/q/161195] nope -- I am quite deliberately running a 32 bit Python on my 64 bit OS (I have some custom c

Re: [Distutils] distutils.util.get_platform() - Linux vs Windows

On Tue, Aug 20, 2013 at 9:00 AM, wrote: > That's strange. I'm on Python 3.3.1, and it seems to me that get_platform() > derives the value from uname for OS X, similar to Linux. > > (osname, host, release, version, machine) = os.uname() > ... > elif osname[:6] == "darwin": > i

Re: [Distutils] distutils.util.get_platform() - Linux vs Windows

On Fri, Aug 16, 2013 at 2:18 AM, wrote: > It seems distutils.util.get_platform() semantically differs on Windows and > Linux. > > Windows: the return value is derived from the architecture of the > *interpreter*, hence for 32-bit Python running on 64-bit Windows > get_platform() = 'win32' (32-

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

On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore wrote: >> 3) I'd rather not have to mess with PATHEXT, and I particularly don't >> want to have to tell my students to do it -- environment variables are >> a pain, and somehow PATHEXT has been fragile for me (and I don't use >> Cygwin) > > Nobody is su

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

Just $0.02 from a user... I'm primarily an OS-X user these days, but have to do Windows once in a while, and help others do Windows (including as an intro to Python instructor) Once I discovered setuptools "develop" mode, I never looked bak -- it is simpl;y THE way to develop code, particularly i

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

On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft wrote: > There is something like 200 total bdist_msi on PyPI and 5k bdist_wininst. > To put numbers into perspective, there are ~180k total files uploaded to > PyPI. I don't hink this means that the installers aren't widely used, I think it mean the

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

On Mon, Jul 15, 2013 at 10:11 AM, Paul Moore wrote: > of Steve Dower, I guess :-)) Powershell is a *great* step up from cmd, could we use a powershell script to launch python scripts? Maybe it wouldn't be any easier to update than an exe, but it might be more accessible. >> Of course, what MS is

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

On Sat, Jul 13, 2013 at 12:59 PM, Paul Moore wrote: >> 2. This sounds like something that needs fixed on Windows. Even if you say >> ``-m`` for pip then things are still broken by default for any other package >> on PyPI that installs a script. So this feels like something wrong with >> Python on

Re: [Distutils] $MACOSX_DEPLOYMENT_TARGET mismatch

On Wed, Jul 3, 2013 at 12:12 PM, Alan wrote: > Well, I found out that if before compiling my python I set > > export MACOSX_DEPLOYMENT_TARGET=10.3 > > and then do all the rest, then I get easy_install to work. cool - well done. > So, somehow my python (or setuptools) need to build for "10.3". >

Re: [Distutils] $MACOSX_DEPLOYMENT_TARGET mismatch

This is really a build question, rather than a distributuion question -- I"d try the pythonmac list: http://mail.python.org/mailman/listinfo/pythonmac-sig I recall that readline is a bit of a pain on the Mac, but don't recall the solution (nor am I running 10.8 yet). Good luck, -Chris On Wed,

Re: [Distutils] wxPython and wx

On Fri, Jun 7, 2013 at 12:56 AM, Yuval Greenfield wrote: > I realize we don't want to start squat-wars. But pypi's wx is a 5 liner that > absolutely no person would ever want installed. At the least, pip should > warn me when I install "wx" that it's probably not what I'm looking for. This isn't

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

On Tue, Jun 4, 2013 at 9:55 AM, Ronald Oussoren wrote: >> $ otool -L python >> python (architecture ppc): >> /Library/Frameworks/Python.framework/Versions/2.7/Python >> (compatibility version 2.7.0, current version 2.7.0) >> /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

On Tue, Jun 4, 2013 at 10:06 AM, Ronald Oussoren wrote: >>> This is not ideal, but works good enough for now. In the long run this >>> should likely be replaced by the compressed tags sets from PEP 425 (at the >>> cost of a much longer file names). >> >> I think now may be the "long run". > > Ma

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth wrote: > That would make sense. Can you come up with code to detect that a > newly compiled extension is universal, and that a Python is? It looks like distutils.util.get_platform() now does the right thing for knowing what the currently running pyton

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

On Tue, Jun 4, 2013 at 1:23 AM, Ronald Oussoren wrote: > This isn't really a problem, distutils uses labels for the set of supported > architectures as the architecture label in binary distributions (e.g. > pyobjc_core-2.5-py3.4-macosx-10.8-intel.egg for an egg that supports the > 'intel' set

[Distutils] Fwd: Binary Wheels and "universal" builds on OS-X

Folks, Accidentally let this slip off the list... -Chris -- Forwarded message -- From: Chris Barker - NOAA Federal Date: Mon, Jun 3, 2013 at 1:33 PM Subject: Re: [Distutils] Binary Wheels and "universal" builds on OS-X To: Daniel Holth On Mon, Jun 3, 2013 at 9:57

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

Darn! this slipped off the list -- I hate it when lists aren't set with the reply-to address as the list... On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth wrote: > ppc is not completely dead? I have one under my desk, though truth be told, I haven't turned it on in a good while... Which is a good

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

And Ned, Thanks for your offer to write something up -- looking forward to it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317

Re: [Distutils] Binary Wheels and "universal" builds on OS-X

r needs to make some choice: If a matching universal binary is found -- use it If a non-universal binary is found that matches the currently running python -- then what? install it with a warning? raise an exception? -Chris > > On May 31, 2013 6:30 PM, "Chris Barker - NOAA Fede

[Distutils] Binary Wheels and "universal" builds on OS-X

HI Folks, A few of us over on the pythonmac list have been hashing out how best to support binary packages on OS-X. The binary wheel option seems very promising. However, there is one Mac-specific issue that does not seem to be addressed: On OS-X, binaries can be "universal" -- what this means i