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

On Thu, Aug 22, 2013 at 8:17 PM, Nick Coghlan ncogh...@gmail.com 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

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 web

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 p...@telecommunity.com wrote: On Mon, Aug 26, 2013 at 11:15 AM, Donald Stufft don...@stufft.io wrote: There is always a cost. In this case mostly in complexity and start up

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 very,

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

On Nov 1, 2013, at 11:25 PM, Marcus Smith qwc...@gmail.com 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

Re: [Distutils] Handling the binary dependency management problem

On Dec 5, 2013, at 1:40 AM, Paul Moore p.f.mo...@gmail.com 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

Re: [Distutils] Handling the binary dependency management problem

On Dec 4, 2013, at 11:35 PM, Ralf Gommers ralf.gomm...@gmail.com 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!

Re: [Distutils] Handling the binary dependency management problem

On Dec 5, 2013, at 1:12 PM, Oscar Benjamin oscar.j.benja...@gmail.com 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

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] 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

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

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

Re: [Distutils] Working toward Linux wheel support

On Jul 17, 2015, at 1:19 PM, Daniel Holth dho...@gmail.com 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

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] 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

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

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

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

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

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

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

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

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

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

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] 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??? >

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

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 <graffatcolmin...@gmail.com>

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;

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] 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

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] 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

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.

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

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

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] ,

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

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

Re: [Distutils] PEP 517 again

was a package with a c extension that was optionally built. That's the rare case. Regular old pure-python packages are the usual case, and a lot easier. -CHB 2017-08-31 16:29 GMT-05:00 Chris Barker <chris.bar...@noaa.gov>: > On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith <n...@pobo

[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

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

[Distutils] Is ensurepip still a thing?

I'm updating some instructions for my students, in which the first thing I do is have them run ensurepip: $ python3 -m ensurepip --upgrade which resulted in: $ python3 -m ensurepip --upgrade Looking in links: /var/folders/ym/tj87fc850yd6526nbrn14rxmgn/T/tmpwc8nd6oj Requirement already

[Distutils] Re: Is ensurepip still a thing?

For completeness' sake: accidentally sent offline. -- Forwarded message -- From: Chung Tzu-ping Date: Tue, Aug 7, 2018 at 1:54 PM Subject: Re: [Distutils] Re: Is ensurepip still a thing? To: Chris Barker - NOAA Federal Replies inline On 7 Aug 2018, at 23:43, Chris Barker

[Distutils] Re: Is ensurepip still a thing?

On Tue, Aug 7, 2018 at 9:16 AM, Donald Stufft wrote: Ensurepip is the mechanism that Python uses to bundle pip with Python. We > didn’t add pip to the stdlib, we added ensurepip to the stdlib. In 3.x the > makefiles and macOS/Windows installers will automatically run ensurepip > (however in both

[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

[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

<    1   2   3   4