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

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

Re: [Distutils] How to eliminate on part of a package?

frankly, I'd give up n find_packages -- it's not that magic, it's just a convenience function so you don't need to hand-specify them. But in this case, you're doing something weird, so I"d just be explicit. Though what I'd probably really do is make the client and server completely separate

[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

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] 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] PEP 517 again

On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan wrote: > >> Do the Linux distros use pip to build their packages? > > > > Not that I am aware of. > > Fedora's build macros for Python projects currently rely on running > setup.py directly, but we've been considering switching to

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 9:23 PM Nick Coghlan wrote: since it > doesn't reliably distinguish between "this cached wheel was downloaded > from a repository" and "this wheel was generated locally with a > particular version of Python". It shouldn't have to. sigh. > PEP 517

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

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 11:03 AM, Nathaniel Smith wrote: > > Surely the build system should know how to correctly name the wheel it > builds. > > It's probably worth mentioning the specific problem that motivated pip > to start doing this. > > It used to be standard, and is still

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 9:04 AM, Donald Stufft wrote: > I'm a bit confused -- are we talking about the backwards compatible > path to the future -- or the end-game? > > > Pip purposely overrides what setuptools tags the wheel with in order to > make it extremely specific to the

Re: [Distutils] PEP 517 again

On Thu, Aug 31, 2017 at 8:57 AM, Paul Moore wrote: > > As to using pip to build wheels -- there is good reason to do that > > now, but in s post PEP 517 world, one would call the build system > > directly to build a wheel-- after all, all pip should be doing is > > calling

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

> conda-build doesn't produce or consume wheels. It works by creating a > clean > > conda environment and running a shell script to install the python > package > > into that environment To be really clear -- conda build doesn't directly use ANY build/install system. All files produced by the

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 12:50 PM, Paul Moore wrote: > Me too. At the moment, I only expect two backends of any substance - > your flit backend and xoviat's setuptools one. But I only know of one > frontend, namely pip - and talk of projects like tox or twine acting > as

Re: [Distutils] PEP 517 again

t->wheel protects the user against the known-to-be-an-issue bug > that the backend doesn't ensure wheel equivalence. pip can not protect the user from a poorly written back-end. And it shouldn't try. * Chris Barker has pointed out that backends have no reason to support > sdists now. &

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

I've thought for ages that we could transition to a more sane system by convention: "your setup.py, after being imported, will have a "setup_params" attribute that is a dict that can be passed to setup()." So tools that want metadata, etc. without actually running an install could do; import

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft wrote: > Donald, what do you think? IIRC, you were most keen on going > sdist->wheel where possible, and I don't think you've commented on > Paul's suggestion yet (apologies if I've overlooked a response). > > > I still think it

Re: [Distutils] PEP 517 again

On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore wrote: > > Suppose you > > have a frontend like pip that when given a source directory and asked > > to build a wheel, wants to implement that as: > > - build sdist > > - unpack sdist > > - build wheel from unpacked sdist > >

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] new PyPI: a rant from a package maintainer

On Fri, Aug 4, 2017 at 5:42 PM, Lucas Boppre Niehues wrote: > > The long description was originally Markdown, and converted to RST by > pandoc. I would 100% understand if this conversion triggered some bug. > It's a good idea to run docutils on it yourself -- but in any

Re: [Distutils] new PyPI: a rant from a package maintainer

one point: I probably should have named it something other than /legacy/, > yes, it should have -- names matter! and having a "legacy" in teh name when there is not "modern" or "current", or, indeed, anything else is very confusing. pypi.org, might as well get it all done at once. It might

Re: [Distutils] Which commercial vendor?

On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner wrote: > Chances are, there will be a package or two that you rely on that is not >> in conda defaults (maintained by Continuum) or currently in conda-forge. So >> you can pip-install those few -- but what if they aren't on PyPi

Re: [Distutils] Which commercial vendor?

On Wed, Apr 5, 2017 at 6:41 PM, Nick Coghlan wrote: > PayPal Engineering put together a decent write-up of their path > towards adopting that model last year: > https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/ Thanks for that link. We're a much

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] 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] Maintaining a curated set of Python packages

On Fri, Dec 16, 2016 at 5:51 AM, Daniel Holth wrote: > One possibility to consider is that virtualenv itself is a bad idea. Why > should the Python interpreter executable, rather than the program being > run, determine the set of packages that is available for import? > well,

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

On Thu, Dec 15, 2016 at 8:29 PM, Glyph Lefkowitz wrote: > At the beginning of your story you mentioned the GUI client - *that* is > the missing piece ;). I've been saying for years that we need a Python.app > that lets you easily bootstrap all this stuff: walk you

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] Maintaining a curated set of Python packages

As pointed out by others, there are external groups doing "curating". conda-forge is one such project, so I'll comment from that perspective: It's difficult because the definition of compatibility is highly dependent on > > the consumer's environment. For example, C extension compatibility will

Re: [Distutils] PEP 517: Build system API

On Mon, Nov 28, 2016 at 10:01 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 November 2016 at 17:53, Chris Barker <chris.bar...@noaa.gov> wrote: > >> Why not just have a single pth file, maintained by the build > >> tool, for all editable installs? >

Re: [Distutils] PEP 517: Build system API

On Thu, Nov 24, 2016 at 3:10 PM, Paul Moore wrote: > Honestly, I don't see what's so bad about pth files. They are a > standard supported Python approach. Maybe setuptools' use of them is > messy? exactly. The fact that setuptools over-uses (abuses?) pth files doesn't

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 4:32 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Nov 23, 2016 at 3:14 PM, Chris Barker <chris.bar...@noaa.gov> > wrote: > > > Please, please, let's figure SOMETHING our here - editable installs (or > > "develop" inst

Re: [Distutils] PEP 517: Build system API

On Wed, Nov 23, 2016 at 6:35 AM, Thomas Kluyver wrote: > Questions: > 1. Editable installs. The PEP currenly specifies a hook to do an > editable install (like 'pip install -e' or 'setup.py develop') into a > given prefix. I don't think that specifying a prefix is

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

On Fri, Nov 4, 2016 at 11:29 PM, Nick Coghlan wrote: > If I understand correctly, conda-forge works on the same basic > principle - reviewing the publishers before granting them publication > access, rather than defending against arbitrarily malicious code at > build time. >

Re: [Distutils] Current Python packaging status (from my point of view)

Final note after a long thread: Just like Nick pointed out in his original post (if I read it right) , the pip vs the conda approach comes down to this: Do you want to a system to manage the whole stack? or do you want a system to manage Python packages? Personally, I think that no matter how

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote: > It would buy *me* flexibility to use python.org build of Python, or my > own builds. And not to have to wait for conda to release a build of a > new version. you are perfectly free to make your own conda package of python

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 5:02 PM, Matthew Brett wrote: > Anaconda has an overwhelming advantage on Windows, in that Continuum > can bear the licensing liabilities enforced by the Intel Fortran > compiler, and we can not. Technically, that's an advantage that a commercial

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 10:56 AM, Matthew Brett wrote: > But - it would be a huge help if the PSF could help with funding to > get mingw-w64 working. This is the crucial blocker for progress on > binary wheels on Windows. for what it's worth, this is a blocker for

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote: > Even on the "hard" cases like Windows, it may be possible to define a > standard approach that goes something along the lines of defining a > standard location that (somehow) gets added to the load path, and > interested

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 3:39 AM, Nick Coghlan wrote: > I don't think there's much chance of any of this ever working on > Windows - conda will rule there, and rightly so. Mac OS X seems likely > to go the same way, although there's an outside chance brew may pick > up some of

Re: [Distutils] Current Python packaging status (from my point of view)

On Thu, Nov 3, 2016 at 2:34 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 2 November 2016 at 23:08, Chris Barker <chris.bar...@noaa.gov> wrote: > > After all, you can use pip from within a conda environment just fine :-) > > In my experience (some time ago) doing so

Re: [Distutils] Current Python packaging status (from my point of view)

Hey Matthew, > [1] There seems to be some animosity among pip supporters and conda > > supports, or at least a perception that there is. > > I don't know whether there is animosity, but there is certainly > tension. Speaking personally, I care a lot about having the option to > prefer pip.

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 11:31 AM, Donald Stufft wrote: > Sure. Do whatever you want, I don’t think anyone here thinks you > absolutely must use pip. :) [1] > indeed -- and IIUC, part of the thrust of Nick's post was that different package managers serve different use-cases --

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 9:49 AM, Nick Coghlan wrote: > No, as the post was about the fundamental and irreconcilable > differences in capabilities, not the incidental ones that can be > solved if folks choose (or are paid) to put in the necessary design > and development time.

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 9:57 AM, Donald Stufft wrote: > > On Nov 2, 2016, at 12:49 PM, Nick Coghlan wrote: > > > > I also mean 2.6 vs 2.7 vs 3.4 vs 3.5 vs 3.6, etc > Of course, but that has nothing to do with the package management system... > There are

Re: [Distutils] Current Python packaging status (from my point of view)

On Wed, Nov 2, 2016 at 7:32 AM, Nick Coghlan wrote: > > He mentioned that conda allows you to > > manage the python run-time itself, which is in deed a nice feature, but > > getting a python run-time as never been the hard part (maybe on Linux if > you > > want a different

Re: [Distutils] Current Python packaging status (from my point of view)

On Tue, Nov 1, 2016 at 5:19 AM, Nick Coghlan wrote: > It isn't that simple, as what you really want to automate is the > *release process*, where you upload an sdist, and the wheels *just > happen* for: > > - the Python versions you want to support (e.g 2.7, 3.4, 3.5) > - the

Re: [Distutils] Current Python packaging status (from my point of view)

On Tue, Nov 1, 2016 at 2:50 AM, Nick Coghlan wrote: > > I wrote some lines, but I deleted my thoughts about the topic > "Automating wheel creation", since > > I am a afraid it could raise bad mood in this list again. That's not my > goal. > > I currently see 3 main ways that

Re: [Distutils] Module Installation Issues

> > I think Ryan may have typed that command at a Python prompt rather than >> a system command prompt. Unfortunately the distinction often isn't clear >> in examples, because the experienced developers writing the instructions >> are used to guessing which commands are Python and which are system

Re: [Distutils] When can we kill Python 2.6 support?

> Looking at pure usage numbers for "modern" versions of pip (6, 7, and 8) for downloading from PyPI I see the usage is ~3% of downloads are via Python 2.6. And a lot of those may be CI systems for packages that still support 2.6 deprecate away! -CHB On Sat, Sep 3, 2016 at 1:36 PM,

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

[Distutils] What role to eggs still play?

Hi all, starting a new thread, but this is related to the setuptols-_lite discussion, and the legacy formats discussion. In another thread Donald had a footnote: [1] We can tackle egg at a later point, when setuptools either has support > for Wheels > or is less needed. So I'm wondering

Re: [Distutils] Future of setuptools and buildout

On Thu, Aug 18, 2016 at 10:17 PM, Wes Turner wrote: > setuptools does all of these, yes? but think of these in terms of when >> they come into play: >> >> build time: >>- building a package >> > > - building c extensions > - building NumPy (fortran,) > exactly! which

Re: [Distutils] Future of setuptools and buildout

On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth wrote: > And a while back I argued against setuptools-lite, because I thought it > would not solve the poor extensibility problem that stems from its basic > distutils derived design... which includes all the classes and subclasses

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 >

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

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

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 <chris.bar...@noaa.gov> wrote: > it looks like the OP is looking for the license to setuptools, not > matplotlib. > > (MPL's licence f

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 >

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

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

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

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

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

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 >

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(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317

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

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 >

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

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

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

On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 May 2016 01:55, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-i

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

On Fri, May 6, 2016 at 9:39 AM, Donald Stufft <don...@stufft.io> wrote: > On May 6, 2016, at 11:54 AM, Chris Barker <chris.bar...@noaa.gov> wrote: > > So my point is about scope-creep -- if you want the PyPa tools to solve > all these problems, then you are re-inventing c

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

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

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

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

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

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)

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

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

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

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

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

  1   2   3   4   >