[Distutils] PyPi not allowing duplicate filenames

Hi all, PyPi does not allow duplicate file names -- this makes lots of sense, because you really don't want people to go to PyPi one day and grab a file, and then go there another day, grab a file with exactly the same name, and have it be a different file. However We are all too human, and

Re: [Distutils] warning about potential problem for wheels

On Wed, Oct 14, 2015 at 9:54 AM, Antoine Pitrou wrote: > > IS that the case: > > """ > > Note that my recently retired computer was 64 bit and had SSE but didn't > > have SSE2 (I'm fairly sure - CPU was some budget AMD model) > > """ > > > > granted, such machines are probably really really rare,

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 9:56 AM, Dave Forgac wrote: > This was discussed recently here: > https://github.com/pypa/packaging-problems/issues/74 > and on this list at other times. Though the above issue was pretty focused on restoring a deleted file without any changes -- which seems like a no-bra

Re: [Distutils] warning about potential problem for wheels

On Wed, Oct 14, 2015 at 1:16 PM, Oscar Benjamin wrote: > Numpy's Windows installer bundles several BLAS binaries with different > levels of SSE and this was the initial reason for not providing Windows > wheels. > indeed -- but IIRC, SSE2 made a pretty big difference, but SSE3 not so much -- thou

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 1:04 PM, Donald Stufft wrote: > > And it just seems pedantic to say: hey -- you've already put that one > there > > -- maybe even two minutes ago, so there is NO WAY to fix your mistake. If > > it happens quickly, then no one has downloaded it, it hasn't made its way > > t

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 1:20 PM, Ionel Cristian Mărieș wrote: > ​This reminds me of Gmail's "unsend" feature where email would be delayed > 10 seconds or something, giving a window to press the unsend button. > FWIW, I am a big fan of that -- and use it with remarkably frequency. -- maybe I'm j

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 1:59 PM, David Cournapeau wrote: > But I'm talking about the cases of "whoops! I really wish I hadn't >> uploaded that one". We can improve the tooling (some discussion on this in >> this thread right now...), but people are people and some of us are stupid >> and/or carel

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 3:26 PM, Donald Stufft wrote: > On October 14, 2015 at 6:24:55 PM, Chris Barker (chris.bar...@noaa.gov) > wrote: > > > another note-- conda has teh concetp of a "build" that's tacked > > on teh release for conda pacakges. > > &

Re: [Distutils] Remove distutils, was: red, green, refactor ...

On Wed, Oct 21, 2015 at 9:34 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > I ask myself: Why a standard? I see that a standard is very important if > there will be > several implementations (for example TCP/IP, protocols like HTTP, SMTP, > IMAP, ...) > > But here a single implementat

[Distutils] Time for a setuptools_lite??

This is kind-of related to the othe thread: "Remove distutils, was: ..." But more specific, so I thought I'd start a new one. Here are my thoughts: We had distutils -- there was a lot it didn't do that the "Masses" needed, so setuptools was born. It proved to be useful to a lot of people, and g

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 10:03 AM, Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > why does that have to be in setuptools ?! > it doesn't have to be in setuptools at all -- I suppose I should have defined more clearly what I meant: setuptools_lite would be a package that does all t

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 10:17 AM, Paul Moore wrote: > On 21 October 2015 at 17:42, Chris Barker wrote: > > So why not have a setuptools-lite that only does the building? > In general, this sounds like a reasonable idea. But, there are the > usual problems: > > 1. Someone

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 12:26 PM, Donald Stufft wrote: > On October 21, 2015 at 3:13:11 PM, Chris Barker (chris.bar...@noaa.gov) > wrote: > > > > replace all your "import setuptools" with "import setuptool_lite" would > be > > clear what the int

Re: [Distutils] Time for a setuptools_lite??

> > > "some subset of what setuptools provides" > > > > So my proposal is here is to provide a way for users to easily use jsut > that > > subset. > > https://pip.pypa.io/en/stable/reference/pip_install/#build-system-interface note above: *easily* use just that subset. All you need to do is writ

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 2:53 PM, Paul Moore wrote: > As I've already said, we have a plan for that, it's > just happening slowly (apparently too slowly for some people, but > rather than helping with it they seem happier to propose alternative > approaches that we've typically considered in the

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 4:52 PM, Robert Collins wrote: > > Hmm, now that I think about it, maybe I can just banish setuptools from > my > > setup.py, stick with distutils, and then make sure to use pip to actually > > invoke anything -- so it will inject setuptools, but only use the bits we > > n

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 7:27 PM, Robert Collins wrote: > > I guess I wasn't clear -- the idea was to force myself to use pip > install, > > rather than ever doing a plain > > > > setup.py install or > > setup.py develop > > > > so: > > pip install ./ > > or > > pip install -e ./ > > > > this wa

Re: [Distutils] What's special about numpy, scipy, ...was: Remove distutils, was: red, green, refactor ...

On Thu, Oct 22, 2015 at 8:47 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > > I have a dream: For packaging and building package provides only > **data**. Data is condition-less: No single "if", "def" or method call. > Just data: json or yaml ... > > > > Even for complex pack

Re: [Distutils] Undelying design is fundamentally difficult to extend was: Remove distutils, was: red, green, refactor ...

On Thu, Oct 22, 2015 at 9:15 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > If setuptools in inside Python, then different versions of Python each > have their matching version included. > > If a package has the need for newer version of setuptool, it provides the > hint somewhere: re

Re: [Distutils] Time for a setuptools_lite??

On Thu, Oct 22, 2015 at 11:45 AM, Marcus Smith wrote: > Give me some +1s folks, and I'm willing to crank it up again... and rally >>> for help to make it as accurate as I know to make it. >> >> +1 -CHB Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R

Re: [Distutils] Time for a setuptools_lite??

Sorry all -- on vacation and only semi-online for a while... I'd managed to miss Flit's creation, so I simply wasn't aware of it. > > Now that I've had a chance to remedy that oversight, yes, flit sounds > exactly like what I meant, so it could be worth recommending it ahead of a > full distutils/

Re: [Distutils] The future of invoking pip

wow! a really long thread here. Trying not to duplicate too much. I am coming primarily from the perspective of someone that teaches python to beginners (I'm also a user and package developer, but I, myself, can deal with any of these options...) My perspective as a user of pip, but not a develope

Re: [Distutils] The future of invoking pip

On Sat, Nov 7, 2015 at 3:53 PM, Antoine Pitrou wrote: > Well, the problem is that "python -m pip" isn't any better. If you > don't know what the current "pip" is, then chances are you don't know > what the current "python" is, either. > sure you do (well, maybe not, but all you know is that when

Re: [Distutils] The future of invoking pip

On Mon, Nov 9, 2015 at 3:27 AM, James Bennett wrote: > Python scripts directly and without having to do hackery with > supporting/requiring 'python -m' or similar is too useful and commonly > used. So faced with either (essentially) forcing a trend of every > command-line tool having to be invoke

Re: [Distutils] The future of invoking pip

On Thu, Nov 12, 2015 at 11:16 PM, Nathaniel Smith wrote: > > > 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 re

Re: [Distutils] Installing packages using pip

On Fri, Nov 6, 2015 at 8:06 AM, Paul Moore wrote: > That's the correct command, but you need to run it from the Windows > command prompt, not from within IDLE. > Now that we are talking about how to invoke the installer on other threads... This is NOT the least bit a rare mistake for newbies. M

Re: [Distutils] Installing packages using pip

On Fri, Nov 13, 2015 at 12:09 PM, Nathaniel Smith wrote: > On Nov 13, 2015 12:00 PM, "Alexander Walters" > wrote: > > > > import pip > > pip.install(PACKAGESPEC) > > > > something like that? > > This would be extremely handy if it could be made to work reliably... But > I'm skeptical about wheth

Re: [Distutils] New Design Landed in Warehouse

On Sun, Nov 22, 2015 at 2:58 PM, Wolfgang Maier < wolfgang.ma...@biologie.uni-freiburg.de> wrote: > Useful content starts only 2/3 down the first page. The large "pip >> install six" snippet probably doesn't deserve being that proeminent >> (or being there at all), and is ironically redundant wit

Re: [Distutils] draft PEP: manylinux1

nice, idea, but libX11.so.6 libXext.so.6 libXrender.so.1 libGL.so.1 These are all X11, yes? pretty much any workstation will have these, but in general, servers won't. Someone on this thread suggested that that's OK -- don't expect a GUI package to work on a linux box without

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith wrote: > Glyph told us last week that this proposal is exactly how the > cryptography package wants to handle their openssl dependency: > https://www.mail-archive.com/distutils-sig@python.org/msg23506.html > > well, SSL is a pretty unique case --

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 11:48 AM, Matthew Brett wrote: > > 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. > > That's exactly h

Re: [Distutils] draft PEP: manylinux1

> On Thu, Jan 21, 2016 at 11:55 AM, Robert T. McGibbon > wrote: > >> >> > These are all X11, yes? pretty much any workstation will have these, >> but in general, servers won't. >> > >> > Someone on this thread suggested that that's OK -- don't expect a GUI >> package to work on a linux box without

Re: [Distutils] draft PEP: manylinux1

OK, I'll try to stop being emotional here :-) 2016-01-22 3:47 GMT+01:00 Chris Barker - NOAA Federal >: > > > > I'm skeptical because I > > tried to to that for years for OS-X and it was just too much to do. And > the > > infrastructure was there. >

Re: [Distutils] draft PEP: manylinux1

On Mon, Jan 25, 2016 at 10:49 PM, Robert T. McGibbon wrote: > On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: > >> Given that we're starting now ( not a year or two ago) and it'll take >> a while for it to r

Re: [Distutils] draft PEP: manylinux1

On Tue, Jan 26, 2016 at 3:56 PM, Nathaniel Smith wrote: > > Well, the people who know what they're doing are still recommending > CentOS 5 today, and we don't know what we're doing :-). > well, yes, there is that. I sure don't. But the threshold for changing is higher than for starting fresh. Tr

Re: [Distutils] draft PEP: manylinux1

On Wed, Jan 27, 2016 at 1:37 AM, David Cournapeau wrote: > > I will make sure to let the manylinux effort know when we decide to move > to Centos6 as the base system. > Thanks -- do you have any idea how many of your customers are running systems that old? i.e. have you stuck with CentOS5 becau

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

Context: I'm maintaining a number of conda packages of various packages, some of which are mine, some others, some pure python, some extensions, etc. The way conda build works is you specify some meta data, and a build script(s), and conda: sets up an isolated environment in which to build. in

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

ll do -- in fact, I was pretty sure this was working earlier stay tuned. -CHB > cycle. > > -Rob > > On 30 January 2016 at 04:48, Chris Barker - NOAA Federal > wrote: > >>> Requirement already satisfied (use --upgrade to upgrade): gsw==3.0.3 > from > >>

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

it jsut worked! This is really, really frustrating...did the downgrade, then re-upgrade of pip somehow fix this? really, really weird. OK -- well, I'm done for now with pip for building conda packages -CHB > > -Rob > > On 30 January 2016 at 04:48, Chris Barker - N

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

On Fri, Jan 29, 2016 at 2:43 PM, Nathaniel Smith wrote: > This is the point where I'd probably start adding print statements to my > local copy of pip. E.g. grep for that "requirement already satisfied" > message and then have it print out sys.path as well. To me this still > smells like some sim

Re: [Distutils] Fwd: setup('postinstall'='my.py')

On Fri, Feb 5, 2016 at 8:39 AM, AltSheets Dev < altsheets+mailingli...@gmail.com> wrote: > > consider adding some code to the installer itself > Wouldn't it be great if setuptools.setup provided that option, and > OS-independent? > well, no. setuptools is a bit of an (ugly?) amalgamation of build

[Distutils] What's up with PyPi maintenance?

Probably not the right list but: There are a number of folks having issue siwth new PyPi pacakges not being found by search: https://bitbucket.org/pypa/pypi/issues/412/my-package-doesnt-show-up-in-search clearly issues have been posted to the project, but has been going on a for a while, with se

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

On Fri, Mar 18, 2016 at 4:16 PM, Noah Kantrowitz wrote: > Just to make it explicit, if anyone wants to submit a patch with a cogent > explanation of what was wrong I'm sure it would get fixed ASAP. Good to know -- if issues aren't commented on, it's hard to know if a PR will get reviewed, eithe

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

On Fri, Mar 18, 2016 at 9:16 AM, Brett Cannon wrote: > When do we expect that? A lot of people rely on the current system, we >> really need to find a way to maintain it 'till it's replaced. >> > > Do realize that this is in regards to the search box, not the ability for > PyPI to keep standing t

Re: [Distutils] For maximum performance, Python packages are best installed as zip files.

one other note: on systems with aggressive virus scanning, python startup can ber REALLY slow. _maybe_ zipped packages would help with that. (or maybe not -- I haven't tested) -CHB On Mon, Apr 11, 2016 at 6:41 AM, Nick Coghlan wrote: > On 11 April 2016 at 23:30, Ionel Cristian Mărieș > wrote

Re: [Distutils] How to add GDAL as a dependency to a Python package

setting gdal as a dependency is only going to work if one of these is true: * There is a binary wheel on PyPi for gdal (which is very hard to do, though with teh manylinux effort, maybe there will be some day) * the system on which you are trying to install is all set up to compile gdal -- which

Re: [Distutils] How to add GDAL as a dependency to a Python package

On Wed, Apr 13, 2016 at 12:02 AM, Luí­s de Sousa < luis.de.so...@protonmail.ch> wrote: > Thank you for the reply Chris. > > I just tried to install pygdal directly from PiPY on a stock Ubuntu > distribution and it fails [0], even if I supposedly have all the necessary > headers installed. > exact

Re: [Distutils] How to add GDAL as a dependency to a Python package

On Wed, Apr 13, 2016 at 12:02 AM, Luí­s de Sousa < luis.de.so...@protonmail.ch> wrote: > Thank you for the reply Chris. > > I just tried to install pygdal directly from PiPY on a stock Ubuntu > distribution and it fails [0], even if I supposedly have all the necessary > headers installed. > I too

Re: [Distutils] The mypy package

e from using it forever. And note that it's possible for someone to put up a useful web site on a free hosting service, attach it to their domain name, and then abandon it -- sure, there may be someone out there that finds that site useful years from now -- but those are the breaks. -CHB

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 8:48 AM, David Wilson wrote: > Namespaces seem like a great idea, then these problems disappear > entirely, huh? as far as I can tell, namespaces greatly expand the pool of available names, but other than that, we've got the same problem. -CHB -- Christopher Bark

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:30 AM, Alexander Walters wrote: > We absolutely do not. Names are first come, first serve, in perpetuity. I'm suggesting that the "in perpetuity" bit is NOT a good way to go -- packages are abandoned, and the longer this goes on, the more issues will arise. > Changi

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:41 AM, David Wilson wrote: > > huh? as far as I can tell, namespaces greatly expand the pool of > available > > names, but other than that, we've got the same problem. > > They seem to have worked well enough from the 1980s through to the 3.5bn > or so Internet users we

Re: [Distutils] The mypy package

On Mon, Apr 18, 2016 at 9:37 AM, Alexander Walters wrote: > Greatly expanding the pool of names solves the problem. > some of it, maybe, but not the problem at hand -- mypy has already put itself up as "mypy-lang", an namespace would be pretty much the same thing. if you do pip search mpypi, yo

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

You've made a strong case, and this is probably not where PyPi should go -- but it would hardly be a disaster: > The idea of expiring out names has been brought up recently to resolve an > issue of two packages, one popular and large; another someone's weekend > project. The issue here is not t

Re: [Distutils] Name arbitration on PyPI (was: The mypy package)

On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco wrote: > >> 1. PyYAML is a package that would be de-registered in such a scheme. > It > > > and you don't think ANYONE would be willing to take on the miniscule > amount > > of work to maintain the name? Plus there would be any number of other > >

Re: [Distutils] The mypy package

On Tue, Apr 19, 2016 at 7:59 AM, Nick Coghlan wrote: > However, as others have noted, we don't really have the resources to > administer a PyPI name dispute resolution system - when there are legal > issues, the PyPI admins can escalate matters to the PSF Board (but those > are fortunately rare)

Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

On Tue, Apr 19, 2016 at 9:45 AM, Ronny Pfannschmidt < opensou...@ronnypfannschmidt.de> wrote: > Instead of overtaking, > how about clearly marking packages as abandoned/maintained clearly > pointing out the mark was imposed by community action > I think that would be a good idea -- and maybe star

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

Interesting. Good evidence that the "first come first served, and then you get to keep it forever" is not ideal. As someone pointed out in the other thread, we probably don't want to change policy on existing packages, but maybe it would be good to get *some* policy in place for when warehouse g

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

On Thu, Apr 21, 2016 at 2:24 PM, Alexander Walters wrote: > On 4/21/2016 15:02, Chris Barker wrote: > >> Good evidence that the "first come first served, and then you get to keep >> it forever" is not ideal. >> > > Criminal violations of trademark are evi

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 3:33 AM, Donald Stufft wrote: > I'd actually prefer not using JSON for something that is human > editable/writable because I think it's a pretty poor format for that case. > It > is overly restrictive in what it allows (for instance, no trailing comma > gets > me every time

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 3:28 PM, Paul Moore wrote: > On 4 May 2016 at 23:11, Chris Barker wrote: > > so it could be purely declarative, but users could also put code in > there to > > customize the configuration on the fly, too. > > That basically repeats the mistake tha

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 7:45 PM, Nick Coghlan wrote: > This configuration vs customisation distinction is probably worth > spelling out for folks without a formal software engineering or > computer science background, so: > fair enough -- good to be clear on the terms. > Configuration is diffe

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 8:09 PM, Nick Coghlan wrote: > I know I'm one of the folks that has historically been dubious of the > "just use setup.cfg" idea, due to the assorted problems with the > ini-style format not extending particularly well to tree-structured > data (beyond the single level of

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

We've spent a huge amount of effort on reaching the point where pretty > much everything *can* be made pip installable. Heck, *PyQt5*, which is > my personal benchmark for a probably-totally-unpackageable package, > announced last week that they now have binary wheels on pypi for all > of Win/Mac/L

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Wed, May 4, 2016 at 11:57 PM, Robert Collins wrote: > > No. Old pip new package will break, new pip old package is entirely safe > AFAICT. That's the goal, yes? So I think we need to get less obsessed with backward compatibility: pip will retain (for along time) the ability to install, bui

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 2:10 AM, Nathaniel Smith wrote: > ...The main thing I want to point out though, is that all of these > problems you're raising are complications caused entirely by wanting > to avoid build isolation in the name of simplicity. If each package > gets its own isolated build en

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 2:47 AM, Nathaniel Smith wrote: > > When you introduce isolation, the build will only have the standard > > library + whatever is declared as a dep: and pyqt5 has no source on > > PyPI. > so build isolation isolates you from arbitrary system libs? now you NEED to ship all

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

Last post! sorry to have not kept up last night > to call the new feature setup_requires but some prefer to eliminate > > uncertainty by calling it bootstrap_requires. > > The main advantage of a new feature name is that when someone searches > the internet for "python bootstrap_requires", the

Re: [Distutils] moving things forward

On Thu, May 5, 2016 at 3:21 PM, Greg Ewing wrote: > Chris Barker wrote: > > OK -- that's more or less my thought -- if it's python that gets run, >> then you've got your config generator built in -- why not? >> > > The difference is that the confi

Re: [Distutils] moving things forward

On Thu, May 5, 2016 at 10:45 PM, Greg Ewing wrote: > Even if python is available, you might not want to run > arbitrary code just to install a package. > > If a config file can contain executable code, then it > can contain bugs. Debugging is something the developer of > a package should have to

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 4:32 PM, Nathaniel Smith wrote: > > You do know that we're on our way to re-writing conda, now, don't you? > :-) > > > > I think we need to be careful of scope-creep... > > conda did not invent the idea of creating separate python environments > for different tasks :-) I'

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Thu, May 5, 2016 at 6:37 PM, Robert Collins wrote: > > Thats good. It occurs to me that scientific builds may be univerally > broken because folk want to avoid easy-install and the high cost of > double builds of things. E.g. adding bootstrap_requires will let folk > fix things? > scientific

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 5:55 AM, Nick Coghlan wrote: > > And maybe it's good to keep "new style" configuration clearly separate. > > Part of my motivation for suggesting re-using setup.cfg is the > proliferation of packaging related config sprawl in project root > directories - setup.py won't be g

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote: > The "Python-with-imports" case is the status quo with setup.py, and we > already know that's a pain because you need to set up an environment > that already has the right dependencies installed to enable your > module level imports in order to

Re: [Distutils] ez_setup.py can not get setuptools

ez_setup.py is pretty darn old. Any reason you can't: python -m pip install setuptools ? -CHB On Fri, May 6, 2016 at 12:11 AM, Benedek Zoltan via Distutils-SIG < distutils-sig@python.org> wrote: > Hi, > > I don't know what happened recently. Usually I install setuptools by a > script using t

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Fri, May 6, 2016 at 9:39 AM, Donald Stufft wrote: > On May 6, 2016, at 11:54 AM, Chris Barker wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-inventing conda -- better to simply > adopt conda (or fork it

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan wrote: > On 7 May 2016 01:55, "Chris Barker" wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-inventing conda -- better to simply > adopt conda (or fo

Re: [Distutils] moving things forward

On Sat, May 7, 2016 at 6:17 AM, Greg Ewing wrote: > Do you expect that > >> projects ... should (somehow) contain simplified instructions on how to >> build the various C/Fortran extensions supplied in the bundle as >> source code? >> > > Essentially, yes. I'm not sure how achievable it would > b

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sat, May 7, 2016 at 11:18 AM, Brett Cannon wrote: > What fields there will be and their semantics ... > >1. Format version (so just deciding on a name -- which also includes > whether it should be top-level or in a subsection -- and initial value) > 2. The actual bootstrap fiel

Re: [Distutils] comparison of configuration languages

On Sat, May 7, 2016 at 6:04 PM, Brett Cannon wrote: For both options I hear "pick a new format", which suggests we might as > well do it from the get-go for clear separation of the new stuff and just > bite the bullet instead of simply postponing a decision; it isn't like our > format options are

Re: [Distutils] who is BDFL for the boostrap/requires declaration? (was: moving things forward)

On Sun, May 8, 2016 at 5:49 AM, Nick Coghlan wrote: > The reason I think "bootstrap" is a better name at this point I *really* don't want to add to the bike-shedding of the name at this point -- I really don't care. I was just trying to see if I was misunderstanding something, as it didn't see

Re: [Distutils] comparison of configuration languages

> > "pymeta" feels very "inessentially weird" to me [1]. yeah... setup.toml ??? -CHB -- 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] moving things forward (was: wheel including files it shouldn't)

On Sun, May 8, 2016 at 5:31 AM, Nick Coghlan wrote: > > any python developer is going to > > run into these issues eventually... > > Aye, I know - conda was one of the systems I evaluated as a possible > general purpose tool for user level package management in Fedora and > derivatives (see > > h

Re: [Distutils] comparison of configuration languages

Really? writing Yet Another Markup Language (YAML :-) ) CAN'T be the simplest, best option. > After further consideration, and pytoml's author's comment about the spec changing without a version increase, I think we might be better off rolling our own. > > I like the general simplicity, and woul

Re: [Distutils] comparison of configuration languages

On Tue, May 10, 2016 at 1:54 AM, Paul Moore wrote: > I would love to use YAML. I really would. But for pip, we need a > robust, easy to vendor Python implementation conda has been using yaml forever (with pyyaml) , and whatever problem is has (and there are many), I don't think I've ever seen a

Re: [Distutils] PEP for specifying build dependencies

One other question: Is it just examples or is "build" being defined as "build a wheel"? i.e. there are times one might want to build a package without building a wheel -- just it install it yourself, or to put it in another package format -- conda, rpm, what have you. In conda's case, building a

Re: [Distutils] PEP for specifying build dependencies

On Fri, May 13, 2016 at 1:09 PM, Nathaniel Smith wrote: > But, the plan *is* to make wheels the standard way to build packages -- > that will be in the next pep :-). I'm not sure I'd call it "lock down", > because there's nothing that will stop you running setup.py bdist_rpm or > whatever. But ou

Re: [Distutils] comparison of configuration languages

On Fri, May 13, 2016 at 11:22 AM, Brett Cannon wrote: > No need to think; the decision is made and it's TOML. I know Chris doesn't > mean to stir up trouble, > I got a bit out of sync with the conversation -- sorry for the noise. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency

Re: [Distutils] If you want wheel to be successful, provide a build server.

On Wed, May 25, 2016 at 8:27 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > I think providing a self hostable build server which can be started with > one command > would be such a project. The manylinux Docker container is heading in that direction already. I suggest you consider h

Re: [Distutils] If you want wheel to be successful, provide a build server.

On Thu, May 26, 2016 at 11:22 PM, Wes Turner wrote: > > "conda-forge is a github organization > containing repositories of conda recipes. > Just to be clear -- while conda-forge is about conda packages, a good deal of the CI integration stuff would apply just as

Re: [Distutils] matrix: python_versions x supported_plattforms, cross-compiling vs VM

Not that this isn't an issue, but: On Fri, May 27, 2016 at 5:34 AM, Daniel Holth wrote: > So this was a problem with eggs too. Let's say ZODB 3.0.1 was just > released. You are happily using 3.0.0, the next version is a minor upgrade, > but there are no precompiled packages for 3.0.1, so your bu

Re: [Distutils] How to build python-packages depends on the output of other project

First, what you have is not all that inelegant -- it is the way to do it :-) But there are a few options when you are wrapping a C/C++ lib for python: Do you need to access that lib from other extensions or only from the one extension? IF others, then you pretty much need to build a shared lib a

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

On Sat, Jul 23, 2016 at 12:22 PM, Nathaniel Smith wrote: > OTOH, if we give up on that part of the idea, then it becomes much easier > :-). It'd be straightforward for PyPI to provide a "how to donate to this > project" box on each project page, that has links to whatever donation > processing se

Re: [Distutils] bulk upload

On Mon, Jul 25, 2016 at 8:55 AM, Robin Becker wrote: > In our private readonly pypi we have 93 releases. I don't think that > burden should fall on pypi. However, it's not clear to me if I should push > micro releases to pypi and then remove them when another release is made. > Is there a way to

Re: [Distutils] pip3 subversion user

On Thu, Aug 4, 2016 at 11:36 AM, Weatherby,Gerard wrote: > Apologies in advance if this is the wrong list for the question; if so, > a pointer to the correct one would be appreciated. > > I'm trying to user the subversion option of pip3 to install a package; I > can use > sudo pip3 install svn+ht

Re: [Distutils] license for setuptools

it looks like the OP is looking for the license to setuptools, not matplotlib. (MPL's licence file is here: https://github.com/matplotlib/matplotlib/blob/master/LICENSE/LICENSE) but setuptools does not appear to have one: https://github.com/pypa/setuptools and it is a pypa package, so this is k

Re: [Distutils] license for setuptools

Sorry for the noise -- I was way too late to this game -- blib in my email, I guess. -CHB On Fri, Aug 12, 2016 at 10:01 AM, Chris Barker wrote: > it looks like the OP is looking for the license to setuptools, not > matplotlib. > > (MPL's licence file is here: https://github.

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

On Tue, Aug 16, 2016 at 8:51 AM, Brett Cannon wrote: > One thing to remember is that Windows can't read tar files natively while > it can for zip files. Now you can easily download tools on Windows to read > tar files and thanks to Bash on Windows you even have it included once you > turn that fe

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

On Tue, Aug 16, 2016 at 9:10 AM, Donald Stufft wrote: > > Ah, I knew I was forgetting something. I think we should hold off on > preventing egg uploads until setuptools can download and install wheels. > Aren't we trying to get to the point where setuptools doesn't download and install anything ?

Re: [Distutils] Future of setuptools and buildout

> > Which brings us to a question that I'm meaning to ask for a while. > > It looks like we're close to removing all mentions of setuptools in pip. > When this happens, it looks like pressure is going to start to mount on > setuptools to drop the ability to install packages and limit itself on > be

<    1   2   3   4   >