Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Tue, May 19, 2015 at 10:18 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: What if instead of focusing on pip being able to install more than just python packages, we made sure that a virtualenv was as strict subset of, say, a conda environment? This way, going from virtualenv to,

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

On Tue, May 19, 2015 at 1:27 PM, Paul Moore p.f.mo...@gmail.com wrote: And maybe all that needs to be is a gitHub project with build scripts. But I had little luck in getting any traction that way. That is, until we had Anaconda, conda and binstar --- an infrastructure that provides a way

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Tue, May 19, 2015 at 1:19 PM, Wes Turner wes.tur...@gmail.com wrote: So it might make sense to actually allow folks to push conda to budding web developers, if conda allowed installation (and environment management) of sdist packages on PyPI. So perhaps it would be good if *this* worked:

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Tue, May 19, 2015 at 3:04 PM, Paul Moore p.f.mo...@gmail.com wrote: Yeah, I'm trying to never build anything for myself, just consume binaries. Having all binaries built by the conda people is a bottleneck. it is -- though the group of conda people is growing... Having pip auto-build

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Tue, May 19, 2015 at 10:58 AM, Paul Moore p.f.mo...@gmail.com wrote: Sure. Doesn't have to be the same way, but the user experience has to be the same. absolutely. But maybe that's not going to cut it -- in a way, we are headed there now, with a contingent of people porting pypi

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

lost track of where in the thred this was, but here's a conda recipe I found on gitHub: https://github.com/menpo/conda-recipes/tree/master/libxml2 don't know anything about it. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206)

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Wed, May 20, 2015 at 12:57 AM, Nick Coghlan ncogh...@gmail.com wrote: This is why I'm such a big fan of richer upstream metadata with automated conversion to downstream formats as my preferred long term solution - this isn't a pip vs conda story, it's pip vs conda vs yum vs apt vs MSI vs

Re: [Distutils] [Python-Dev] Single-file Python executables (including case of self-sufficient package manager)

On Fri, May 29, 2015 at 7:23 AM, Paul Sokolovsky pmis...@gmail.com wrote: An example of a product that does this is Chef, they install their own Ruby and everything but libc into /opt/chef to completely isolate themselves from the host system. this sounds a bit like what conda does --

Re: [Distutils] Dynamic linking between Python modules

On Thu, May 21, 2015 at 1:12 PM, Paul Moore p.f.mo...@gmail.com wrote: built from wheel right now, with no special tools. A conda recipe that simply installs a wheel in it's build script would do just that. That sounds about right, from what I've seen of conda builds. You could probably do

Re: [Distutils] Dynamic linking between Python modules

On Thu, May 21, 2015 at 11:12 AM, Jonathan Helmus jjhel...@gmail.com wrote: it sounds like a tool that is capable of converting between conda packages and wheel files converting from a wheel to a conda package should be very doable (and may already be done). But the other way around is not

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Wed, May 20, 2015 at 3:46 PM, Nick Coghlan ncogh...@gmail.com wrote: On 21 May 2015 at 03:37, Chris Barker chris.bar...@noaa.gov wrote: As such, it _could_ play the role that pip+wheel (secondarily pypi) play in the python ecosystem. In practice, it can't, as conda is entirely

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

On Wed, May 20, 2015 at 5:43 PM, Nick Coghlan ncogh...@gmail.com wrote: One of my hopes for the metadata extension system in PEP 426 is that we'll be able to define extensions like fedora.repackage, debian.repackage or conda.repackage which include whatever additional info is needed to

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Wed, May 20, 2015 at 5:20 PM, Nick Coghlan ncogh...@gmail.com wrote: Coping with this problem is also why injecting setuptools when running vanilla distutils projects is one of the secrets of pip's success: Ahh! THAT is the role pip plays in building. It's the way that you get setuptools

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On Tue, May 19, 2015 at 5:21 AM, Paul Moore p.f.mo...@gmail.com wrote: If conda did everything pip did (and that includes consuming wheels from PyPI, not just sdists, and it includes caching of downloads, autobuilding of wheels etc, etc.) hmm...what about half-way -- conda does everything

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

On Tue, May 19, 2015 at 11:10 AM, Paul Moore p.f.mo...@gmail.com wrote: to be the same. I suppose I could deliver the static libs themselves, along with the headers, etc, but that does get ugly. Hmm, that seems to me to be something of a non-goal. If you publish wheels, 99.999% of people

Re: [Distutils] Working toward Linux wheel support

On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower steve.do...@python.org wrote: I actually like two ideas for Windows (not clear to me how well they apply on other platforms), I think this same approach should be used for OS-X, not sure about Linux -- on LInux, you normally have normal ways to get

Re: [Distutils] Working toward Linux wheel support

On Wed, Aug 12, 2015 at 6:05 PM, Nathaniel Smith n...@pobox.com wrote: (2) the special hard-coded tag centos5. (That's what everyone actually uses in practice, right?) Is LSB a fantasy that never happened? I haven't followed it for years -CHB Compare with osx, where there are actually a

Re: [Distutils] Working toward Linux wheel support

On Thu, Aug 13, 2015 at 10:52 AM, David Cournapeau courn...@gmail.com wrote: So this is a basic list I got w/ a few minutes of scripting, could we define this list (or somethign like it) as Python-Linux-Standard-Base-version X.Y Then we have a tag to use on binary wheels, and clearly defined

Re: [Distutils] PIP Installation Question

On Thu, Aug 6, 2015 at 9:05 AM, Rachel Krabacher krabacher.rac...@gmail.com wrote: My name is Rachel and I am a master's student using Python as part of my thesis work analysis. I have found a package online and have downloaded it from github, but am having difficulties getting Python to

Re: [Distutils] Working toward Linux wheel support

On Tue, Jul 21, 2015 at 9:38 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I think it would be great to just package these up as wheels and put them on PyPI. that's the point -- there is no way with the current spec to specify a wheel dependency as opposed to a package dependency. i.e

Re: [Distutils] Working toward Linux wheel support

TL;DR -- pip+wheel needs to address the non-python dependency issue before it can be a full solution for Linux (or anything else, really) The long version: I think Linux wheel support is almost useless unless the pypa stack provides _something_ to handle non-python dependencies. 1) Pure Python

Re: [Distutils] Working toward Linux wheel support

On Fri, Jul 17, 2015 at 8:46 AM, Antoine Pitrou solip...@pitrou.net wrote: Due to the fact Linux binary wheels don't exist, conda is even more useful on Linux... True -- though it's at least possible, and certainly easier than on Mac and Windows, to build it all yourself on Linux. -CHB --

Re: [Distutils] Working toward Linux wheel support

On Sun, Jul 19, 2015 at 11:00 PM, Nick Coghlan ncogh...@gmail.com wrote: However, Nate has a specific concrete problem in needing to get artifacts from Galaxy's build servers and installing them into their analysis environments - let's help him solve that, on the assumption that some *other*

Re: [Distutils] Working toward Linux wheel support

On Sun, Jul 19, 2015 at 10:50 PM, Nick Coghlan ncogh...@gmail.com wrote: The intended use case is Build once, deploy many times. This is especially important for use cases like Nate's - Galaxy has complete control over both the build environment and the deployment environment, but they

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

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

[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

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 12:26 PM, Donald Stufft <don...@stufft.io> 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 > &

Re: [Distutils] Time for a setuptools_lite??

On Wed, Oct 21, 2015 at 10:17 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 21 October 2015 at 17:42, Chris Barker <chris.bar...@noaa.gov> wrote: > > So why not have a setuptools-lite that only does the building? > In general, this sounds like a reasonable idea. Bu

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

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

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

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: [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

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

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,

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

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

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

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

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

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

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

Re: [Distutils] warning about potential problem for wheels

On Wed, Oct 14, 2015 at 3:40 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 13 Oct 2015 09:59:05 -0700 > Chris Barker <chris.bar...@noaa.gov> wrote: > > > > So even is SSE2 provides little for Python itself, in the usual case, > we'll > > see

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

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

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

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,

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

Re: [Distutils] PyPi not allowing duplicate filenames

On Wed, Oct 14, 2015 at 3:26 PM, Donald Stufft <don...@stufft.io> 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 co

Re: [Distutils] tests location: Use case: new comers and docs.

On Tue, Oct 6, 2015 at 10:38 PM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > Yes, there is not generic "one right way here". > > Yes, let's consider individual use cases. > > My use case are the docs for new comers: > > - https://github.com/pypa/sampleproject > -

Re: [Distutils] warning about potential problem for wheels

On Sun, Oct 11, 2015 at 11:18 AM, Steve Dower wrote: > And it's also not binding on redistributors or package builders, who are > free to add more restrictive requirements. > not binding, but presumably a simple: setup.py build with distutils (or setuptools) will NOT

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

How many people can join a hangout? we may be bumping up against that limit :-) -CHB On Thu, Oct 8, 2015 at 12:58 PM, Nathaniel Smith wrote: > On Oct 8, 2015 09:33, "Nathaniel Smith" wrote: > > > > On Oct 8, 2015 8:14 AM, "Nathaniel Smith"

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I"ve been following this thread and gotten a bit lost. But I do care, because I'm a heavy numpy user, and also because I was involved for years in building pacakges for OS-X, and currently need distribute some of my own stuff that has semi-ugly C lib dependencies (Not as ugly as BLAS.,though :-) )

Re: [Distutils] Where should I put tests when packaging python modules?

On Fri, Oct 9, 2015 at 10:44 AM, Thomas Güttler < guettl...@thomas-guettler.de> wrote: > The question remains: If a new comer asks you "How to package my > python code and its tests?", there should be one default answer > which works for 80% of all cases. > Should be, maybe -- but clearly there

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 10:28 AM, Paul Moore wrote: > ... or thinking again, maybe you mean having multiple packages > (numpy_mkl, numpy_openblas, ...) all of which satisfy a "numpy" > requirement? yes, that is EXACTLY what I meant. the idea here is that if you build a

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 11:28 AM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static and each wheel declares its own dependencies >

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 9, 2015 at 11:44 AM, Oscar Benjamin wrote: > Assuming it's tied to the operating system it doesn't matter surely. When > pip runs on Windows it can ignore dependencies that apply to other > platforms so I don't see how this case makes it more complex. >

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

On Mon, Sep 28, 2015 at 11:19 AM, Matthew Iversen wrote: > For example, the two are different for flask, virtualenv, setuptools, > sopel, numpy > these are some pretty significant, complex packages. I have trouble finding an objective reasoning that one method is to be >

[Distutils] pip install from source dir??

I can't seem to find a way to pip install from a source dir -- not a tarball. Why would I want to do that? In this case, it's because I'm trying to build conda packages for python packages that have compiled C code, and are not using setuptools. On Windows, you need to use setuptools in order

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Fri, Oct 2, 2015 at 2:45 PM, Nathaniel Smith wrote: > > I would rather see an sdist format that can be introspected *without* > > running code or a build tool. indeed -- this has come up a lot on this list, for binary dists, too, of course. but "build script as turing

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

I'm not sure if I understand what Nathaniel is getting at, but... > As the very simplest example, every package that uses the numpy C API > > gets a runtime dependency on "numpy >= [whatever version happened to > > be installed on the *build* machine]". > From my point of view, it's not a

Re: [Distutils] pip install from source dir??

ks, -CHB > On October 2, 2015 at 5:38:29 PM, Chris Barker (chris.bar...@noaa.gov) > wrote: > > I can't seem to find a way to pip install from a source dir -- not a > > tarball. > > > > Why would I want to do that? > > > > In this case, it's be

Re: [Distutils] pip install from source dir??

PYTHON is the python in conda's current build environment -- this will assure it used the right pip. Thanks all, this is working great. -CHB > Erik > > > On October 2, 2015 at 5:38:29 PM, Chris Barker (chris.bar...@noaa.gov) > wrote: > >> I can't seem to find a way to pip i

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

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

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

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

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

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

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 >

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

imes) but 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

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

ing the 8 development > will 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 > <chris.bar...@noaa.gov> wrote: > >>> Requirement already satisfied (use

[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.

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

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

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

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

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 <chris.bar...@noaa.gov > >: > > > > I'm skeptical because I > > tried to to that for years for OS-X and it was just too much to do. And > the > > infr

Re: [Distutils] draft PEP: manylinux1

On Mon, Jan 25, 2016 at 10:49 PM, Robert T. McGibbon <rmcgi...@gmail.com> 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 wh

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

[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

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

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

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

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

On Thu, Apr 21, 2016 at 2:24 PM, Alexander Walters <tritium-l...@sdamon.com> 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

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

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 >

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.

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

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

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

On Wed, May 4, 2016 at 3:28 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 4 May 2016 at 23:11, Chris Barker <chris.bar...@noaa.gov> wrote: > > so it could be purely declarative, but users could also put code in > there to > > customize the configuration on th

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

Re: [Distutils] moving things forward

On Thu, May 5, 2016 at 3:21 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> 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

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)

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

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

<    1   2   3   4   >