[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

>> * Is there any practical operational or performance limits on the number of >> mounted XARs you can have? E.g. what's the impact of deploying say a few >> thousand XARs on any particular machine (generally, of Linux and macOS - I'm >> not as concerned about Windows :) > We have tiers

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

On Jul 16, 2018, at 18:14, Nick Terrell wrote: > > I collected the XAR benchmark numbers. I spent some time today > investigating what > exactly is causing the difference between native and XAR start times. The > native > installation I was benchmarking against used >

[Distutils]Re: Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers

Cooper Ry Lees wrote on 7/13/18 13:51: Today Facebook Open Sourced a competitor to PEX and other zip based distribution methods for Python (and potentially other languages). Basically it's claim to fame is start up time for large modules being similar to regular on file system modules due to

Re: [Distutils] Renaming this list to python-packaging

Donald Stufft wrote: I don’t think we can rename a mailing list easily, we can create a new one and archive the old one but that has a lot of churn and breaks people’s filters, etc. Although it should be easier to rename if the list is migrated to Mailman 3 first. Please contact

Re: [Distutils] Deprecating/Removing OpenID/Google login support for PyPI

Donald Stufft wrote: > > * Very few people actually are using OpenID or Google logins as it is. In one > month we had ~15k logins using the web form, ~5k using basic auth, and 62 > using Google and 7 using OpenID. This is a several orders of magnitude > difference. > * Regardless of how you

Re: [Distutils] library development patterns

Nick Coghlan wrote: > The tox model is the one we decided to natively support in Fedora as > well - while there's only ever one "full" Python 3 stack in the main > repos (with all the distro API bindings, etc), there are also > interpreter-only packages for other still supported and/or still >

Re: [Distutils] library development patterns

Chris Withers wrote: > For me, I use travis-ci coupled with a few local virtualenvs for canary > versions. Some people like tox here, I never got on with it. For me, tox is transformative. While there are a couple of usability issues that my clone army seems to be remiss in fixing, for the most

Re: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses

On Dec 13, 2017, at 19:39, Dustin Ingram wrote: > > It seems like a small amount of convenience in exchange for a > significant increase in complexity to me. I can’t speak to the complexity, but it’s very definitely an important use case. Imagine when Python 3.10 is out; do you

[Distutils] PEP 345, 566, 508 version specifiers and OR clauses

I'm about to release a new version of importlib_resources, so I want to get my flit.ini's require-python clause right. We support Python 2.7, and 3.4 and beyond. This makes me sad: requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3' Of course, I'd like to write this like: requires-python =

[Distutils] Multiple package authors

I think I implicitly knew this, but as I've just released a package (to be announced soon) that actually has multiple authors, I found out first hand that PyPI rejects uploads where the author-email field isn't a completely valid email address, and that there is no support for multiple author

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Jun 25, 2017, at 11:33 AM, Nick Coghlan wrote: >I'd favour "Participate" over any variant of "Contribute", as without >context, "Contribute" makes me think of financial support in the >crowdfunding/tip jar sense. "Participate" may mean two different things. * Here's the development home,

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

On Jun 24, 2017, at 05:34 PM, Brett Cannon wrote: >So my question/idea is if it would make sense to have separate, explicit >development and documentation URLs in the PyPI metadata? Wholehearted +1 I already use PyPI as the first stop for finding out about a library or Python project. I have a

Re: [Distutils] RFC: PEP 541 - Package Index Name Retention

On Jan 13, 2017, at 10:08 AM, Lukasz Langa wrote: >PEP: 541 >Title: Package Index Name Retention Overall, +1 I agree with Steve that some short term name squatting may be appropriate. I'm not sure how you would word that in the PEP, but it will probably effectively work itself out anyway. When

Re: [Distutils] Announcement: TLSv1.2 will become mandatory in the future

On Jan 10, 2017, at 08:24 AM, Donald Stufft wrote: >python3 -c "import urllib.request,json; > print(json.loads(urllib.request.urlopen('https://www.howsmyssl.com/a/check').read())['tls_version'])" For Python 3.5: python3 -c "import urllib.request,json;

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

On Dec 01, 2016, at 10:45 AM, Freddy Rietdijk wrote: >Having a compatible set of packages is not only interesting for developers, >but also for downstream distributions. All distributions try to find a set >of packages that are working together and release them. This is a lot of >work, and I

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

On Nov 03, 2016, at 11:08 AM, Glyph Lefkowitz wrote: >I think phrasing this in terms of "perfect" and "good enough" presents a >highly misleading framing. Examined in this fashion, of course we may >reluctantly use the "good enough" option, but don't we want the best option? What are the

Re: [Distutils] Travis-CI is not open source. Was: Current Python packaging status (from my point of view)

On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote: >This is also an area where I'm fine with recommending freemium >solutions if they're the lowest barrier to entry option for new users, >and "Use GitHub + Travis CI" qualifies on that front. I won't rehash the GitHub/GitLab debate, but in some of

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

On Sep 02, 2016, at 05:05 PM, Donald Stufft wrote: >Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3 >years is enough to start deprecating and dropping 2.6? Yes! Cheers, -Barry pgpCalDLuc3vp.pgp Description: OpenPGP digital signature

Re: [Distutils] greater compression on pypi?

On Aug 22, 2016, at 02:29 PM, Daniel Holth wrote: >1. If it's a zip, nested zips like so, > >setup.py >README >(metadata) >data.zip That would be much more disruptive to downstream consumers of sdists. Cheers, -Barry pgpcWwl_cnoP1.pgp Description: OpenPGP digital signature

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

On Aug 22, 2016, at 09:14 PM, Nick Coghlan wrote: >In that case, perhaps the way to go for sdists (at least for now) >would be to continue allowing both .tar.gz and .zip, but disallow >uploading both of them for any given release? I'd prefer allowing uploading of both formats for now, with mild

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

On Aug 17, 2016, at 03:21 PM, Nick Coghlan wrote: >This means that the situation we've managed to get to now is that we >have wheels as a satisfactory replacement for the "binary >distribution" use case, but we haven't even *tried* to replace eggs >for the "standalone path entry" use case. I'm

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

On Aug 15, 2016, at 05:39 PM, Donald Stufft wrote: >so narrowing it down to only .tar.gz and .tgz is pretty safe, but practically >nobody uses .tgz anyways so why bother? I agree with all of your reasoning. FWIW, I personally use .tgz all the time when making backups of things locally, but

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

On Aug 15, 2016, at 03:09 PM, Donald Stufft wrote: >Out of all of these, I think that we can easily remove bdist_dmg, bdist_rpm, >and bdist_dumb. I also believe that there is a strong case for removing >bdist_msi and bdist_wininst. I also think we should consider removing >bdist_egg. +1 for all

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

On Jul 26, 2016, at 01:24 PM, Nick Coghlan wrote: >The PSF has considered this, but there's not a lot of value we could >provide above and beyond other organisations that already do this for >open source projects in general. For example: > >- Software Freedom Conservancy >- Software in the Public

Re: [Distutils] PyPI and GPG Signatures

On May 12, 2016, at 04:34 PM, Donald Stufft wrote: >So my response to this is, let's pretend for a minute that we have the >greatest and most amazing setup for verifying that the key 0x6E3CBCE93372DCFA >belongs to me. What's your next step? How do you verify that I'm allowed to >release for pip?

Re: [Distutils] PyPI and GPG Signatures

On May 12, 2016, at 07:41 AM, Donald Stufft wrote: >I am aware of a single tool anywhere that actively supports verifying the >signatures that people upload to PyPI, and that is Debian's uscan >program. Even in that case the people writing the Debian watch file have to >hardcode in a signing key

Re: [Distutils] comparison of configuration languages

On May 09, 2016, at 08:30 PM, Donald Stufft wrote: >How hard is it to bundle it with pip by copying the source files into >pip._vendor.* Every time another package is vendored, a kitten falls off a unicorn. ;) Cheers, -Barry pgpetwbrYXBeb.pgp Description: OpenPGP digital signature

Re: [Distutils] comparison of configuration languages

On May 08, 2016, at 09:05 AM, Robert Collins wrote: >E.g. use setup.cfg now. Add pybuild.toml later. (btw, terrible name, >as pybuild is a thing in the debian space, and this will confuse the >heck out of folk). https://wiki.debian.org/Python/Pybuild Yes, please don't call it pybuild ;) Also, I

Re: [Distutils] wheel including files it shouldn't

On Apr 27, 2016, at 10:00 PM, Alex Grönholm wrote: >The sdist should include all the source files, including tests and >documentation. In binary distributions, however, they are just dead >weight. Do you want the full documentation and test suites to be installed >for every single dependency when

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On Feb 16, 2016, at 06:01 PM, Matthias Klose wrote: >I know we had such an issue where pip accidentally modified system installed >files, maybe Barry still remembers the details ... I don't, but I hope that should not be a problem these days, with modern pip on modern Debian/Ubuntu systems. We

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

On Feb 11, 2016, at 01:58 PM, Nick Coghlan wrote: >Hmm, I got the py2dsc reference from https://wiki.debian.org/Python/Packaging >but the newer https://wiki.debian.org/Python/LibraryStyleGuide doesn't appear >to mention any particular way of generating the initial packaging skeleton >from the

Re: [Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

On Feb 10, 2016, at 10:08 AM, Paul Moore wrote: >But those people will then find that distributing their sources isn't >something that flit covers, so they'll make up their own approach (if it were >me, I'd probably just point people at the project's github account). > >Once people get set up

Re: [Distutils] The future of invoking pip

On Nov 05, 2015, at 04:08 PM, Donald Stufft wrote: >One benefit of the third option is that we can remove the need to directly >copy the bundled libraries into the pip source code and we can install just >bundle it inside the built zip file. This shouldn't be a problem from Debian's p.o.v. if we

Re: [Distutils] Please don't impose additional barriers to participation (was: build system abstraction PEP)

On Oct 29, 2015, at 10:52 PM, Marcus Smith wrote: >> If python-dev ends up adopting GitLab for the main PEPs repo, then we >> should be able to move the whole process there, rather than needing to >> maintain a separate copy. >> >will that be as open as pypa/interoperability-peps? if it's closed

Re: [Distutils] Uploading stdeb built debs ?

On Oct 10, 2015, at 06:48 AM, Stuart Axon via Distutils-SIG wrote: >Hi,    I built a package of using stdeb, any idea if these are acceptable to >debian + ubuntu, and where to start / who to contact to get a package >included in those distros ? S++ You can contact debian-pyt...@lists.debian.org

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

On Oct 07, 2015, at 09:46 AM, Ben Finney wrote: >So “I'm a big fan of putting tests inside the [Python] package >[directory]” can't be motivated by “Having the tests there in the >installed package”. The two aren't related, AFAICT. It makes it easier for sure. When the tests are inside the

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

On Oct 07, 2015, at 08:18 AM, Donald Stufft wrote: >tox and setup.py test are not really equivalent. There’s no way (to my >knowledge) to test the item outside of a virtual environment. This is >important for downstreams who want to test that the package build and the >tests successfully are

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

On Oct 07, 2015, at 08:35 AM, Marius Gedminas wrote: >I have hopes for 'tox.ini' becoming the standard way to test a Python >project. As do I, modulo outliers of course. I'd like to see 90% of PyPI packages have a tox.ini. Cheers, -Barry pgpxJ0ovIWbuL.pgp Description: OpenPGP digital

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

On Oct 06, 2015, at 05:54 AM, Donald Stufft wrote: >I dislike putting tests inside the package. I'm a big fan of putting the tests inside the package. I've often looked at a package's tests to get a better understanding of something that was unclear for the documentation, or didn't work the way

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

On Oct 06, 2015, at 06:21 AM, Donald Stufft wrote: >FreeBSD relies on ``python setup.py test`` as it's preferred test invocation, >so it apparently doesn't find it useful either. Oh how I wish there was a standard way to *declare* how to run the test suite, such that all our automated tools (or

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

On Oct 06, 2015, at 11:33 AM, David Cournapeau wrote: >I would like to hear their rationale before guessing. It is hard for me to >imagine they would not rather test the binaries rather than from sources. >Something as simple as making sure you have not forgotten runtime >dependencies becomes

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

On Oct 06, 2015, at 08:18 PM, Ben Finney wrote: >Yes, this is a sensible approach: > >* The source package contains all the source files a developer would use > to make further changes and test them. > >* The package for installation contains only those files useful run-time > users, plus

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

On Oct 06, 2015, at 05:41 PM, Donald Stufft wrote: >I’m not sure I understand what you’re advocating here, it sounds like you >want your tests at something like mycoolproject/tests so that they are >importable from mycoolproject.tests… but then you talk about symmetry with >docs/ and tests/ which

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

On Oct 07, 2015, at 08:54 AM, Ben Finney wrote: >Barry Warsaw <ba...@python.org> writes: > >> I'm a big fan of putting the tests inside the package. I've often >> looked at a package's tests to get a better understanding of something >> that was unclear for the

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

On Oct 06, 2015, at 10:44 AM, Antoine Pitrou wrote: >Doesn't / didn't setuptools have something called test_requires? Since I pretty much use tox everywhere these days, I've taken to defining test requirements in my tox.ini rather than my setup.py. Cheers, -Barry pgpDfbZCf3GwZ.pgp

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

On Oct 07, 2015, at 08:51 AM, Ben Finney wrote: >I think the above describes the standard way of declaring the test >runner: The ‘setup.py test’ command. > >Now, I lament that more Python projects don't *conform to* that >standard, but at least it exists. It's *a* standard but not *the*

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

On Oct 06, 2015, at 09:51 AM, Antoine Pitrou wrote: >The PyP"A" should definitely fix its sample project to reflect good >practices. Here's my own sample project. There are actually two git branches, one with an extension module and one with pure Python. https://gitlab.com/warsaw/stupid

Re: [Distutils] PyPI and Uploading Documentation

On May 15, 2015, at 09:48 AM, Donald Stufft wrote: One of the things that this brought to light was that the documentation upload ability in PyPI is something that is not often used* however it represents something which is one of our slowest routes. I use it for all my packages, mostly because

Re: [Distutils] Proper handling of PEP420 namespace packages with setuptools and pip

On Apr 23, 2015, at 07:08 AM, Robert Collins wrote: PEP-420 and legacy packages being mixed for one namespace doesn't work at all today - in principle fixable via changes to both setuptools and importlib - but it was about here that the other openstack folk said 'ok wow, lets just stop using

Re: [Distutils] Get dependencies of a package without full download

On Apr 01, 2015, at 04:14 PM, Thomas Güttler wrote: Is it possible to get the dependencies of a package without full download from pypi? It would be kind of nice if you could get the package's metadata (e.g egg-info/entry_points.txt) out of its PyPI JSON blob:

Re: [Distutils] it's happened - wheels without sdists (flit)

On Mar 30, 2015, at 11:56 AM, Donald Stufft wrote: Honestly, I don’t think that setup.py as a development interface is that bad. Especially when you cargo cult most of a new project's basic infrastructure[*] from one that's already working. Sweat out the first one, then reuse. ;) Cheers,

Re: [Distutils] it's happened - wheels without sdists (flit)

On Mar 31, 2015, at 09:14 AM, Nick Coghlan wrote: We need to build from source not just to ensure our binaries match the published source code, but also because our build systems are designed to let us *patch* the packages before we build them. This is what lets us backport security updates, bug

Re: [Distutils] Google Auth is broken for PyPI

On Feb 10, 2015, at 02:27 PM, Brett Cannon wrote: Does Launchpad support OpenID Connect? If so then migrating to that would solve this. No, I don't believe so. I've just filed this bug: https://bugs.launchpad.net/launchpad/+bug/1420348 Otherwise it may be time to have a serious look at our

Re: [Distutils] Google Auth is broken for PyPI

On Feb 08, 2015, at 11:37 PM, Richard Jones wrote: Google has discontinued support for OpenID, so we're not going to be putting any effort into debugging this issue. I hope you'll continue to support other OpenID providers, e.g. Launchpad. Cheers, -Barry pgpVJAH8ZQaH8.pgp Description:

Re: [Distutils] Python module for use in ‘setup.py’ but not to install

On Jan 19, 2015, at 07:23 PM, Ben Finney wrote: My understanding, based on an answer received elsewhere [0], is that omitting the file from ‘setup.py’ but adding it to ‘MANIFEST.in’ causes it to be included in the sdist but omitted from install targets. I haven't read the whole thread (no time

Re: [Distutils] Bilingual namespace package conundrum

On Jan 13, 2015, at 02:39 PM, Robert Collins wrote: Welcome to hell :) Well, purgatory maybe. I patched the lazr packages I cared about. :) So I dug down ridiculously deep into this when investigating a very similar issue in the openstack space. I have an alternative solution to the ones

[Distutils] Bilingual namespace package conundrum

I hope the following makes sense; I've been a little under the weather. ;) Apologies in advance for the long data-dump, but I wanted to provide as complete information as possible. I have ported Mailman 3 to Python 3.4[*]. While working on various development tasks, I noticed something rather

Re: [Distutils] Bilingual namespace package conundrum

On Jan 01, 2015, at 09:14 PM, Donald Stufft wrote: Why are you puzzled by the notion that something designed to work with a one mechanism for a particular feature probably does not work with a newer, different mechanism for a particular feature? My assumption is that setuptools is ensuring that

Re: [Distutils] Bilingual namespace package conundrum

On Jan 01, 2015, at 03:20 PM, Tres Seaver wrote: That sounds right to me. I never really understood the motivation for PEP 420, but if the presence of that file disables it, then it should ensure the old behavior regardless. The motivation is described in the PEP, but briefly, on (many, most,

Re: [Distutils] stdeb and python dependencies

On Oct 22, 2014, at 05:00 PM, Kelly Goedert wrote: I am new to python. I created a simple python cli application that depends on jsonpickle and plumbum. Using this command python setup.py --command-packages=stdeb.command bdist_deb I was able to create a .deb package. But when I try to install

Re: [Distutils] Immutable Files on PyPI

On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote: Installers and PyPI would then regard 3.1.4-1 as belonging to release 3.1.4, but being a more current build as a distribution file carrying 3.1.4 in its file name. Please don't literally use 3.1.4-1. That will cause all kinds of havoc with the

Re: [Distutils] Immutable Files on PyPI

On Sep 30, 2014, at 02:34 PM, Jeremy Stanley wrote: I'm becoming less and less convinced it actually *is* a source distribution any more. My constant interaction with downstream Linux distro packagers shows a growing disinterest in consuming release tarballs of software, that they would generally

Re: [Distutils] Immutable Files on PyPI

On Sep 30, 2014, at 05:40 PM, Wichert Akkerman wrote: Debian does allow 3.1.4-1-1. I forgot the exact rules, but I seem to remember the package version is considered to start after the last dash. Debian will also sort 3.1.4a after 3.1.4 unlike Python rules, so version “massaging” might be

Re: [Distutils] Immutable Files on PyPI

On Sep 30, 2014, at 04:25 PM, Jeremy Stanley wrote: Good to know. The Debian Developer packaging the majority of the projects I work on must be in that minority. IIRC, the OpenStack packagers were probably the most prominent proponent of release-from-tag. Cheers, -Barry signature.asc

Re: [Distutils] Immutable Files on PyPI

On Sep 28, 2014, at 07:31 PM, Donald Stufft wrote: I'd like to discuss the idea of moving PyPI to having immutable files. This would mean that once you publish a particular file you can never reupload that file again with different contents. This would still allow deleting the file or reuploading

Re: [Distutils] Immutable Files on PyPI

On Sep 29, 2014, at 09:40 AM, Ian Cordasco wrote: That's essentially what I see as the chief use-case for testpypi.python.org. I don't think pypi.python.org needs to support this as well. Simple is better than complex after all :) Can we then make it easy to upload to testpypi via the cli?

Re: [Distutils] Create formal process for claiming 'abandoned' packages

On Sep 20, 2014, at 06:10 PM, Toshio Kuratomi wrote: All distros I can think of have some sort of self-governance whereas pypi is more akin to a bunch of customers making use of a service. Some of the distro policies don't apply very well in this space. Some do, however, so I hope other people

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

On Sep 03, 2014, at 12:24 PM, Reinout van Rees wrote: All of them have ubuntu packages, but especially for gdal we sometimes need a newer version. A PPA can help here, but I thought a wheel could be nice, too. In many cases, it mostly takes an interested person to get Ubuntu and Debian packages

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

On Sep 04, 2014, at 10:39 AM, Marcus Smith wrote: wouldn't that only update it for the *next* release of debian/ubuntu? Generally yes. There's also backports, but that's more effort. https://help.ubuntu.com/community/UbuntuBackports https://wiki.debian.org/Backports Cheers, -Barry

Re: [Distutils] Other ideas from today's packaging meetup at EuroPython

On Jul 25, 2014, at 08:46 AM, Donald Stufft wrote: Yea, I’m not sure whether I like it or not. Probably once we get a for real build farm for PyPI setup that will be a pretty reasonable sized carrot for people to upload sources. That's really the right long-term approach, IMO. I'd like to some

Re: [Distutils] Other ideas from today's packaging meetup at EuroPython

On Jul 24, 2014, at 01:28 PM, Richard Jones wrote: 1. reject wheel uploads in the absence of an sdist in the index (the linux guys were really happy about that as a proposal ;) +1 :) -Barry signature.asc Description: PGP signature ___ Distutils-SIG

Re: [Distutils] PEP440 Local versions idea in rpm/deb?

On May 02, 2014, at 12:01 PM, Marcus Smith wrote: PEP440 has the local version idea to distinguish locally patched projects from upstream versions. http://legacy.python.org/dev/peps/pep-0440/#local-version-identifiers e.g. Django-1.6.4-1 for a locally patched Django-1.6.4 to place on a local

Re: [Distutils] Pycon

On Mar 28, 2014, at 03:06 PM, Daniel Holth wrote: Who is going to pycon? I will be there. I'll be there, for the duration (language summit through sprints). It would be great to hav an OpenSpace or BoF for discussing the intersection of Python packaging issues and distros. -Barry

Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides

On Mar 25, 2014, at 03:35 PM, PJ Eby wrote: I think the correct fix would be to change the nspkg.pth magic to check for PEP 420 support, but unfortunately it seems we may have to use version checking: on rereading PEP 420 I see there's no 'sys.namespace_packages' or similar object that can be

[Distutils] nspkg.pth files break $PYTHONPATH overrides

Apologies for cross-posting, but this intersects setuptools and the import system, and I wanted to be sure it reached the right audience. A colleague asked me why a seemingly innocent and common use case for developing local versions of system installed packages wasn't working, and I was quite

Re: [Distutils] nspkg.pth files break $PYTHONPATH overrides

On Mar 24, 2014, at 05:53 PM, Donald Stufft wrote: See also https://github.com/pypa/pip/issues/3 Hah, yeah. I didn't realize --single-version-externally-managed is implied by --root, and in fact our Debian build scripts often (either explicitly or implicitly) define --root, as is the case in

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

On Feb 05, 2014, at 01:05 AM, Nick Coghlan wrote: That only works if the system site packages is configured to be visible inside the virtual environment - it usually isn't these days. Really? I do this all the time. It prevents downloading gobs of stuff from PyPI that my system already

Re: [Distutils] Warehouse and XMLRPC

On Nov 15, 2013, at 10:12 PM, Donald Stufft wrote: The bulk of XMLRPC has been implemented in Warehouse. It would be great if people who are using the XMLRPC could try it out using the https://preview-pypi.python.org/pypi url. Currently the search API does not work. Are you planning on putting

Re: [Distutils] URL Structure of Packages URLs

On Oct 12, 2013, at 06:15 PM, Donald Stufft wrote: Just to be clear, I don't fault folks for using the /packages/ urls. I was just trying to get some sort of idea if anyone actually used that url structure or not. I also don't plan on breaking anything for people who do. That being said, do you

Re: [Distutils] URL Structure of Packages URLs

On Oct 12, 2013, at 08:50 PM, Floris Bruynooghe wrote: Sounds like this could be addressed with a lintian warning and a long transition time (~2 years) so leaving proper redirects around would be advisable. Sure, but my point was that people will use the most easily discoverable pattern

Re: [Distutils] URL Structure of Packages URLs

On Oct 08, 2013, at 10:44 AM, Donald Stufft wrote: Hrm, I'm assuming these require a file listing at /packages/source/D/ too. Of course these files should probably be using the simple API and not the packages url directly :/ Maybe that URL should be given on the PyPI page for the package? The

Re: [Distutils] Ubuntu says Virtualenv, Pip and Setuptools untrusted

On Jul 27, 2013, at 10:12 AM, Erik Bernoth wrote: did you know that Ubuntu 13.10 (or maybe Debian?) declares those packages as untrusted and asks you twice, if you really want to install them? Is there anything that can be done about that? Um, what? Please provide details. What commands are

Re: [Distutils] Shebang lines, /usr/bin/python, and PEP394

On Jul 26, 2013, at 09:58 PM, Nick Coghlan wrote: Not everybody uses generated script wrappers, though - if there is a hardcoded /usr/bin/env python or /usr/bin/python in a shebang line, the Python build tools won't touch it. There's also a whole lot of software that isn't packaged at all - it's

Re: [Distutils] Shebang lines, /usr/bin/python, and PEP394

On Jul 26, 2013, at 08:38 PM, Paul Moore wrote: There are cases where it's useful and appropriate Sure, I don't disagree. Just that I think the general rule should be: * Use /usr/bin/env in your source tree * Use /usr/bin/$python when installed I think those rules cover the majority of cases.

Re: [Distutils] Shebang lines, /usr/bin/python, and PEP394

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Jul 25, 2013, at 03:37 PM, Philip Jenvey wrote: What's the value of sys.executable in the brave new world of distributions that follow PEP 394? One use case is locating other scripts/executables that might get installed next to sys.executable

Re: [Distutils] Q about best practices now (or near future)

On Jul 17, 2013, at 11:46 AM, Daniel Holth wrote: I'd like to see an ambitious person begin uploading wheels that have no traditional sdist. You're not getting rid of sdists are you? Please note that without source distributions (preferably .tar.gz) your package will never get distributed on a

Re: [Distutils] Q about best practices now (or near future)

On Jul 17, 2013, at 07:56 PM, Paul Moore wrote: The long-term intent is to remove executable setup.py. When this happens, definitely consumers (end users, Python tools like pip, and distro packaging systems) will have some migration work to do. Keeping that manageable will definitely be

Re: [Distutils] Q about best practices now (or near future)

On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote: I imagined that distro packaging tools would end up using the wheel as an intermediate format when building a deb from a source deb. Do you mean, the distro would download the wheel or that it would build it during the build step for the

Re: [Distutils] PEP 439 and pip bootstrap updated

On Jul 10, 2013, at 02:43 PM, Paul Moore wrote: I would find it distinctly irritating if in Python 3.4 I have to type pip3 bootstrap to bootstrap pip - and even worse if *after* the bootstrap the command I use is still pip. (And no, there is currently no pip3 command installed by pip, and even if

Re: [Distutils] PEP 439 and pip bootstrap updated

On Jul 10, 2013, at 09:50 PM, Paul Moore wrote: I think python -m pip should be the canonical form (used in documentation, examples, etc). The unittest module has taken this route, as has timeit. Traditionally, python-dev have been lukewarm about the -m interface, but its key advantage is that it

Re: [Distutils] option #1 plus download_url scraping

On Jun 04, 2013, at 03:23 PM, Noah Kantrowitz wrote: Do you mean you just don't want to update the version number in setup.py before you release? Correct, although on further reflection, if the alternative download site has predictable URLs, then it wouldn't be too difficult to calculate the new

Re: [Distutils] option #1 plus download_url scraping

On Jun 04, 2013, at 04:46 PM, Carl Meyer wrote: On 06/04/2013 04:30 PM, Donald Stufft wrote: I'm interested in the use case. How are generating a release without running setup.py sdist? I think you misunderstood (the way Barry described it wasn't completely clear). If I'm reading it

Re: [Distutils] option #1 plus download_url scraping

On Jun 05, 2013, at 12:16 PM, Donald Stufft wrote: Where are you updating the version information at? And how are you generating a tarball so that it's name has the correct version in it? It depends on the package, but let's say it's in a version.txt file. Your implication is correct though -

Re: [Distutils] option #1 plus download_url scraping

On Jun 05, 2013, at 02:47 PM, Donald Stufft wrote: I'm really just trying to get a sense of your workflow to see if I can make any changes to improve the process for it. One of the big problems with download_url is that the data in setup.py is used in (and influences the content of) the final

[Distutils] option #1 plus download_url scraping

Like many of you, I got Donald's message about the changes to URLs for Cheeseshop packages. My question is about the three options; I think I want a middle ground, but I'm interested to see why you will discourage me from that wink. IIUC, option #1 is fine for packages hosted on PyPI. But what

Re: [Distutils] Merge catalog-sig and distutils-sig

On Mar 28, 2013, at 02:22 PM, Donald Stufft wrote: Is there much point in keeping catalog-sig and distutils-sig separate? Without yet reading the whole thread, I'll just mention that it's probably easier to just retire one or the other mailing lists and divert all discussion to the other one.

Re: [Distutils] [Catalog-sig] Merge catalog-sig and distutils-sig

On Mar 28, 2013, at 03:42 PM, Donald Stufft wrote: Don't care how it's done. I don't know Mailman enough to know what is possible or how easy things are. I thought packaging-sig sounded nice but if you can't rename + redirect or merge or something in mailman I'm down for whatever. Renaming can

Re: [Distutils] pip merges wheel

On Mar 18, 2013, at 02:16 PM, Lennart Regebro wrote: I still think it is unfortunate that we are starting to extend pip to be a tool for developers to create distributions. It would be better of pip was kept as an install tool, and we added the utilities for creating distributions separate. +1.

Re: [Distutils] pip merges wheel

On Mar 18, 2013, at 04:13 PM, Nick Coghlan wrote: Eventually I expect pip will grow a --wheel-only option to run it in strict installer only mode, but the ecosystem is a long way from supporting that being a useful option (especially since there are some cases which will still require falling

Re: [Distutils] Library instability on PyPI and impact on OpenStack

On Mar 04, 2013, at 06:11 PM, Nick Coghlan wrote: My point of view is that the system Python is there primarily to run system utilities and user scripts, rather than arbitrary Python applications. Users can install alternate versions of software into their user site directories, or into virtual

  1   2   3   >