Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 6:09 PM, Donald Stufft wrote: > > I sometimes wonder if we should be folding twine into pip itself Yes please. WTB `pip upload`. -g___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] GnuPG signatures on PyPI: why so few?

of package X that everyone else is using. If there was > a publisher signature, the timestamp server would sign the publisher's > signature asserting 'this signature was valid at time X'. > > On Tue, Mar 14, 2017 at 2:52 AM Nick Coghlan <ncogh...@gmail.com > <mai

Re: [Distutils] GnuPG signatures on PyPI: why so few?

ext signatures rather than encryption <https://github.com/kaepora/miniLock/issues/198>, could potentially address this problem. 4. Cool as that would be, someone would need to design that thing first, and that person would need to be a cryptogr

Re: [Distutils] GnuPG signatures on PyPI: why so few?

> On Mar 12, 2017, at 5:13 AM, Ben Finney wrote: > > Paul Moore writes: > >> One tool that needs improvement to be easier to use for this to happen >> is GPG itself. > > No disagreement from me on that. And indeed, the GnuPG project's chronic

Re: [Distutils] Deprecating download counts in API?

> On Mar 6, 2017, at 3:34 AM, Donald Stufft <don...@stufft.io> wrote: > > >> On Mar 6, 2017, at 1:41 AM, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >> >>> On Mar 5, 2017, at 8:51 AM, D

Re: [Distutils] Deprecating download counts in API?

ented in BigQuery? That said, I'm fully OK with the answer that even a tiny bit of work is too much, and the limited volunteer effort of PyPI should be spent elsewhere. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distlib and wheel metadata

hich depends on 'foo-lib' but pins the transitive closure of all dependencies with '=='. Your CI system could automatically release a new 'foo-app' every time any dependency has a new release and a build against the last release of 'foo-app' passes. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to specify dependencies in Python

> On Jan 16, 2017, at 7:59 AM, Thomas Güttler > wrote: > > I think requirements.txt should be the result of some kind of > Continous-Integration run. > If all tests are successful, then requirements.txt should be created with > "pip freeze". > > This means,

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

> On Jan 11, 2017, at 7:40 PM, Nick Coghlan wrote: > > On 12 January 2017 at 13:00, Donald Stufft wrote: >> This doesn’t work well because it’s not something that pip is going to be >> able to upgrade on Windows, because the .so will be locked when pip

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

> On Dec 22, 2016, at 11:15 PM, Nick Coghlan wrote: > > On 22 December 2016 at 09:08, Chris Barker > wrote: > And there are utilities that let you run a script in a given environment: > >

Re: [Distutils] Can't upload sdist: "File already exists"

> same version) Similarly; I've *definitely* done sdist releases after wheel releases of the same version in the past. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

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

> On Dec 16, 2016, at 5:07 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 16 December 2016 at 20:57, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: > > Anyhow, Xcode is far from perfect - many of the places it touche

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

c generator, or any other dev tool) in the same context as your application code, without actually loading or executing any specific thing from your application code. Virtualenv also lets you easily control which Python version or interpreter (hello, pypy!) is being used in each context. -glyph

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

> On Dec 15, 2016, at 9:23 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 16 December 2016 at 14:29, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: >> On Dec 15, 2016, at 8:18 PM, Nick Coghlan <ncogh...@gmail.com

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

> On Dec 15, 2016, at 8:33 PM, Donald Stufft <don...@stufft.io> wrote: > > >> On Dec 15, 2016, at 11:29 PM, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >> User-curated package sets strikes me as th

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

> On Dec 15, 2016, at 8:18 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 16 December 2016 at 07:14, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: >> On Dec 15, 2016, at 6:39 AM, Donald Stufft <don...@stufft.

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

le to install the entire set by doing something > like: > > $ pip install -r > https://pypi.org/sets/dstufft/my-cool-set/requirements.txt > <https://pypi.org/sets/dstufft/my-cool-set/requirements.txt> Can't people already do this by publishing a package that just depen

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

> On Dec 14, 2016, at 9:41 AM, Chris Barker wrote: > > 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

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

> On Nov 3, 2016, at 10:17 AM, Barry Warsaw wrote: > > 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

Re: [Distutils] Code for inserting paths into system configuration?

stall pip_user_config > python -m pip_user_config > > where the latter would cleverly insert the user bin directory into the > user's configuration. > > Does anyone know of any code to do something like that? This is shell- and platform-specific. This would be a great idea! But it

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

> On Aug 23, 2016, at 1:08 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > ... especially as compared to binary eggs ... Wheels. especially as compared to binary wheels. -g___ Distutils-SIG maillist - Distutils-SIG@p

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

> On Aug 23, 2016, at 12:03 PM, M.-A. Lemburg wrote: > > On 23.08.2016 18:46, Donald Stufft wrote: >> Since it seemed like there was enough here for a proper PEP I went ahead and >> write one up, which is now PEP 527. The tl;dr of it is that: >> >> * Everything but sdist,

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

at order? As a community (and I mean the broader open source community here, not distutils-sig; if anything distutils is way better about this) we have an unfortunate habit of killing potentially-useful-but-sub-optimal stuff, wandering off for half a decade, and then only adding the better thing after th

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

nflate download counts even if they're used by a far smaller number of users. Anyway, like I said: not an expert here, just wanted to make sure the "python for desktop software (even if it's not used much right now)" angle is considered as well. -glyph

Re: [Distutils] license for setuptools

://www.python.org/psf/contrib/ <https://www.python.org/psf/contrib/>) > but that seems very formal. Is there a simpler one that just makes it > implicit that 'submitting a patch/PR = you agree to license that code to the > project for redistribution" or whatever. &

Re: [Distutils] license for setuptools

Thanks for submitting this PR, Ian! :) > On Aug 12, 2016, at 6:24 AM, Ian Cordasco wrote: > > Thanks for that Geoffrey. There's a PR to add it as Jason decided to > accept it. I think we can all relax now. Okay? > > On Fri, Aug 12, 2016 at 8:00 AM, Geoffrey Spear

Re: [Distutils] license for setuptools

The OP specifically asked about setuptools, which is on-topic. In large corporate environments it is standard to have a process that evaluates every single dependency, so setuptools does end up in the bucket with matplotlib since you need it to install. > On Aug 11, 2016, at 8:36 PM, Noah

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

> On Jul 23, 2016, at 12:11 PM, Donald Stufft wrote: > > >> On Jul 23, 2016, at 2:40 PM, Nicholas Chammas > > wrote: >> >> I know a more concrete proposal would have to address a lot of details (e.g. >> like

Re: [Distutils] Outdated packages on pypi

> On Jul 13, 2016, at 1:54 PM, Steve Dower wrote: > > Possibly such user-contributed content would be valuable anyway https://alternativeto.net but for PyPI? :) -glyph___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] Outdated packages on pypi

> On Jul 12, 2016, at 9:54 PM, Donald Stufft <don...@stufft.io> wrote: > > >> On Jul 12, 2016, at 4:45 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: >> >> My feeling is that there should be a "dead man's switch" sort of mechanism >&g

Re: [Distutils] Outdated packages on pypi

chives there's been quite a bit of discussion around messaging to package owners and that sort of thing - and the main sticking point is that someone needs to volunteer to do the work on Warehouse. Are you that person? :) -glyph ___ Distutils

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

> On Jun 22, 2016, at 14:42, Donald Stufft wrote: > > I don’t think these two things need to be bound together. People can already > today depend on platform specific things just by not publishing wheels. > Adding these tags naturally follows that, where people would need to

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

way to do it is probably going to take a lot of discussion. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch PyPA from IRC to Gitter or similar

over IRC, but the effect of those benefits is mostly just prompting me to spend more time staring at chat. Which is not what I want to be doing. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch PyPA from IRC to Gitter or similar

> On Jun 10, 2016, at 6:22 AM, Jason R. Coombs wrote: > > In #pypa-dev, I raised the possibility of moving our PyPA support channels > from IRC to another hosted solution that enables persistence. Opinions about free software vs. federation vs. user experience aside, I

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

> On Apr 18, 2016, at 3:21 PM, Donald Stufft <don...@stufft.io> wrote: > >> >> On Apr 18, 2016, at 6:14 PM, Glyph <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> >> >>> On Apr 18, 2016, at 2:31 PM, Ian

Re: [Distutils] The mypy package

> On Apr 18, 2016, at 3:17 PM, Alex Grönholm wrote: > > This name is unfortunately a bit awkward in the author's native language -- > it is the colloquial word for "babe" or "broad" :) OK, I didn't see that one coming :-). "stapy", then? "static type annotation

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

> On Apr 18, 2016, at 3:11 PM, Donald Stufft wrote: > > If we mandated semver (or something like it) we could make it so that > transferring a name *forced* a major version bump and the new author would be > unable to release anything using a smaller major version number,

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

> On Apr 18, 2016, at 2:31 PM, Ian Cordasco wrote: > > I have in fact offered but the author refuses to accept help from > anyone. They're also the author of the C library (libyaml) and they do > not maintain that either. It's actually quite frustrating as someone >

Re: [Distutils] The mypy package

or TYped PYthon? Nothing shows up in a pip search for that just yet. Just a thought, -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

stead" would be very informative. -glyph > On Apr 5, 2016, at 3:26 PM, Alex Grönholm <alex.gronh...@nextday.fi> wrote: > > You make a valid point. This made me recall something -- there is a > classifier "Development Status :: 7 - Inactive". As a quick fix, pip

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 17, 2016, at 7:44 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > I think making pip do this might be mixing layers too much. Frankly `pipsi´ > does almost the right thing; if `sudo pipsi´ put script symlinks in > /usr/local/bin/ instead of ~/.loc

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 17, 2016, at 7:17 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Tue, Feb 16, 2016 at 6:12 PM, Glyph Lefkowitz > <gl...@twistedmatrix.com> wrote: >> Here, I'll make it for you. Assuming virtualenv is installed: >> >> python -m virtualen

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 17, 2016, at 7:08 PM, Noah Kantrowitz wrote: > > Saying it's a good idea and we should move towards it is fine and I agree, > but that isn't grounds to remove the ability to do things the current way. So > you can warn people off from global installs but until

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

e risk. In fairness though I've never written a clear explanation anywhere of why this is desirable; it strikes me as obvious but it is clearly not the present best-practice, which means somebody needs to do some thought-leadering. So I owe you a blog post. -glyph ___

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

> On Feb 17, 2016, at 2:17 AM, David Cournapeau wrote: > > Sure, but the people I tend to see using `sudo pip` are not the kind of users > where that distinction is very useful. It's hair-splitting but probably correct hair-splitting in terms of how it's detected. > If

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

> On Feb 17, 2016, at 12:55 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Tue, 16 Feb 2016 16:10:34 -0800 > Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: >> >> I am 100% on board with telling people "don't use `sudo pip install´". >

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

> On Feb 16, 2016, at 11:55 PM, Robert T. McGibbon <rmcgi...@gmail.com> wrote: > > On Tue, Feb 16, 2016 at 4:10 PM, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@twistedmatrix.com>> wrote: > This whole section is about a tool to autom

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 16, 2016, at 5:00 PM, Noah Kantrowitz <n...@coderanger.net > <mailto:n...@coderanger.net>> wrote: > > >> On Feb 16, 2016, at 4:46 PM, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> &g

Re: [Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 16, 2016, at 4:33 PM, Noah Kantrowitz <n...@coderanger.net > <mailto:n...@coderanger.net>> wrote: > > >> On Feb 16, 2016, at 4:27 PM, Glyph Lefkowitz <gl...@twistedmatrix.com >> <mailto:gl...@twistedmatrix.com>> wrote: >> &

[Distutils] Don't Use `sudo pip install´ (was Re: [final version?] PEP 513…)

> On Feb 16, 2016, at 4:13 PM, Noah Kantrowitz wrote: > > As someone that handles the tooling side, I don't care how it works as long > as there is an override for tooling a la Chef/Puppet. For stuff like > Supervisord, it is usually the least broken path to install the

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

> On Feb 16, 2016, at 3:05 AM, Matthias Klose <d...@ubuntu.com> wrote: > > On 02.02.2016 02:35, Glyph Lefkowitz wrote: >> >>> On Feb 1, 2016, at 3:37 PM, Matthias Klose <d...@ubuntu.com> wrote: >>> >>> On 30.01.2016 00:29, Nathaniel Smit

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

ses for dynamically linked wheels and fancy new platform library features in newer linuxes. But that can all come later, and none of it needs to have an impact on this specific proposal, right now. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] draft PEP: manylinux1

ically link against from the platform, especially if you're writing desktop apps. On OS X you can do this because /System/*/ is more or less fixed when you are >= some version; on linux less so but it would be very nice to build artifacts for specific versions when possible. -glyph ___

Re: [Distutils] draft PEP: manylinux1

> On Jan 24, 2016, at 2:56 PM, Donald Stufft wrote: > > ... the excellent Barry Warsaw ... Distro work is often thankless (especially here) so I just wanted to echo this: glory to the FLUFL, may his reign be <> short. -glyph___

Re: [Distutils] heads-up on a plot to bring linux wheels to pypi

> On Jan 14, 2016, at 2:12 AM, Nick Coghlan wrote: > > In terms of non-scientific packages, the main group I'd suggest > getting in touch with is pycryptography, as we'll probably want to > baseline a more recent version of OpenSSL than the one in CentOS 5.11. > 1. It's

Re: [Distutils] Building and installing packages on a (unix) system lacking network accesss

penv ; cd - New python executable in tmp-a3e6ab08e84f351d/bin/python2.7 Also creating executable in tmp-a3e6ab08e84f351d/bin/python Installing setuptools, pip, wheel...done. virtualenvwrapper.user_scripts creating /Users/glyph/.virtualenvs/tmp-a3e6ab08e84f351d/bin/predeactivate vir

Re: [Distutils] workflow recommendations to update requirements.txt

> On Dec 15, 2015, at 8:56 PM, Chris Jerdonek wrote: > > Hi, > > I have a development workflow question I was wondering if people on > this list had a recommended solution for. > > Say you're working on a web application that you deploy using a > requirements.txt

Re: [Distutils] The future of invoking pip

h cases. This would go a long way to alleviating the confusion that occurs when users back themselves into one of these corners, and would alert users to potential issues before they become a problem; right now you have to be a dogged investigative journalist to figure out why pip

Re: [Distutils] The future of invoking pip

> On Nov 5, 2015, at 7:34 PM, Robert Collins wrote: > > Why not? (Ignore the language I wrote my pseudocode in, an actual > thing would be a Python script that install would turn into a .exe) It was not clear, in the example that you gave, that I was supposed to

Re: [Distutils] PyPi not allowing duplicate filenames

the HTTP cache or the wheel cache, or how it got there; I also don't want to have to bust a ~200 megabyte cache that saves me hours a day just because there's one bad entry in there. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org https://

Re: [Distutils] PyPi not allowing duplicate filenames

> On Oct 14, 2015, at 10:36 AM, Nathaniel Smith wrote: > > My feeling is that pypi is correct to disallow the mutation of releases once > they become public, but that the ergonomics around this could probably be > improved :-). A more general solution that might be nice to

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

top-level package "tests". This tends to infest the whole package, since then tests import things from each other using 'from tests import ...'. This is recommended by the hitchhiker's guide, and seconded by <http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_2

Re: [Distutils] Unable to login to PyPi

If nobody has time to fix the code for OpenID, is there at least an admin with privileges to associate passwords with people's accounts? -glyph > On Sep 29, 2015, at 03:09, Mike O'Driscoll <mikeodrisc...@gmail.com> wrote: > > I'm completely locked out. > > If there is/

Re: [Distutils] Unable to login to PyPi

Mike, do you have another way to authenticate to the site, or are you locked out until OpenID works again? -g > On Sep 28, 2015, at 14:02, Richard Jones wrote: > > Hi Mike, > > Sorry, but this is a known problem that no-one has time to investigate or fix. > > >

Re: [Distutils] pip merges wheel

, right? What's the rationale for not just preferring wheels if they're available? -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip merges wheel

of pip _could not_ get any worse. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip merges wheel

On Mar 16, 2013, at 5:06 PM, Daniel Holth dho...@gmail.com wrote: Earlier today we merged the existing wheel branch into mainline pip. This adds opt-in wheel install support (built into pip, pip install --use-wheel ...) and the convenient pip wheel ... command for creating the wheels you

Re: [Distutils] Add optional password_command .pypirc value

password storage is always worth working on :). Have you heard of the Keyring module? https://pypi.python.org/pypi/keyring/ It already supports a cross-platform interface to this sort of thing, including the OS X keychain. -glyph ___ Distutils-SIG

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

beforehand, and mature packages try hard to maintain some semblance of a compatible API, even if there is some disagreement over what compatible means. -glyph ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo

Re: [Distutils] PEP 426: proposed metadata caching convention

into, instead of assuming that by some accident of timing we can work out when the software is being installed and call some random function from the bottom of setup.py with a bunch of state scooped out of distutils' internals. The current situation is a total mess. -glyph

Re: [Distutils] PEP 426: proposed metadata caching convention

On Feb 27, 2013, at 11:04 AM, Daniel Holth dho...@gmail.com wrote: What does it have to do in the hook? This: https://twistedmatrix.com/documents/current/core/howto/plugin.html#auto3 While this is theoretically optional - Twisted will behave mostly correctly without it - it noticeably

Re: [Distutils] PEP 426: proposed metadata caching convention

install if they don't wish for that (of course packages have no reason to support that if they don't want to). I pretty much agree. I'd be happy – enthusiastic, even – for Twisted to update to some static metadata expression system. -glyph

Re: [Distutils] Proposal: drop md5 for sha256

On Jul 3, 2012, at 5:50 PM, PJ Eby p...@telecommunity.com wrote: Otherwise, we will have this exact same problem all over again when the replacement secure hash is disabled by a newer version of FIPS. Or, you know, somebody could maintain the dang software and automate the process of

Re: [Distutils] Twisted plugin system and Python packaging

On Sep 25, 2011, at 1:44 AM, P.J. Eby wrote: You may want to note that Twisted isn't the only distribution that ships partial packages that aren't namespace packages. The logilabs packages are (or at any rate were) distributed this way, with a top-level package in one distribution, and

Re: [Distutils] Twisted plugin system and Python packaging

On Sep 24, 2011, at 11:01 PM, P.J. Eby wrote: This really sounds like a bug in pip; top_level.txt is not a replacement for a proper uninstall log. Thanks. It appears that Pip's maintainers are (the teensiest bit grudgingly) coming around to this perspective as well:

Re: [Distutils] Name the software! Package quality tester.

On Mar 9, 2011, at 7:06 AM, Jim Fulton j...@zope.com wrote: They certainly aren't projects in any sense that most people would understand. They are arguably products of projects. Of course, the term product has negative connotations for some folks. Not for everybody! As far as I am

Re: [Distutils] Python version in egg name

On Feb 2, 2011, at 2:49 PM, Matt Chaput wrote: Is there a way to set this value to py2.5 as a configuration option, other than running setup.py using the Python 2.5 executable? Or not have it be part of the egg filename at all? I'm using Python 2.7 as my default Python install but I make

Re: [Distutils] An observation on how system packagers and developers can be friends

On Oct 28, 2010, at 6:08 PM, Tres Seaver wrote: Heh, agreed. That bites me on about every third machine I set up for the first time. The Usual Suspects (TM) are whatever the local packaging system calls the following (and their -dev or -devel packages, if split out): - - zlib - -

Re: [Distutils] distribute and install --root

On May 10, 2010, at 9:14 AM, Nikolaus Rath wrote: Glyph Lefkowitz gl...@twistedmatrix.com writes: On May 9, 2010, at 5:47 PM, Tarek Ziadé wrote: Having .local here looks like a bug to me. Could you create an issue with details ? For what it's worth, I have had similar things happen when

Re: [Distutils] distribute and install --root

On May 10, 2010, at 4:05 PM, Tarek Ziadé wrote: Yes, someone provided this patch a while ago and I've added it (it's --no-user-cfg in 2.6). Do you mean in 2.7? I see it documented here: http://docs.python.org/dev/distutils/builtdist.html, but not here:

Re: [Distutils] distribute and install --root

On May 9, 2010, at 5:47 PM, Tarek Ziadé wrote: Having .local here looks like a bug to me. Could you create an issue with details ? For what it's worth, I have had similar things happen when I had forogtten that I created a ~/.pydistutils.cfg. Have you made sure that there isn't one there?

Re: [Distutils] [sqlalchemy] Re: inability to pass setup.py command line arguments to dependency setups

On May 7, 2010, at 2:08 PM, Michael Bayer wrote: I'd only mention that Storm has a C extension/non C extension flag as well, and only offers one source distribution on Pypi. You have to modify a variable directly within setup.py. Our setup.py features the same capability (its just our

Re: [Distutils] Python people want CPAN and how the latter came about

On Dec 23, 2009, at 4:33 PM, Lennart Regebro wrote: 1/ Missing packages (eg: Twisted is not there) The Twisted guys do not upload their packages to PyPI. I think that's a mistake, but it's hardly PyPI's fault. There is no law saying you have to use CPAN either. For what it's worth, we

Re: [Distutils] Python people want CPAN and how the latter came about

On Dec 21, 2009, at 5:48 PM, David Cournapeau wrote: On Mon, Dec 21, 2009 at 7:13 PM, Lennart Regebro rege...@gmail.com wrote: What nobody still fails to explain in this discussion is what CPAN is and Why Python doesn't already have it. That's not the right question to ask. The problem is

Re: [Distutils] Install time prefixes and data files

On Nov 13, 2009, at 9:01 AM, Wolodja Wentland wrote: This would mean that the *default* install should be PEP 370 compliant or inside a virtualenv and that installing into system paths should be enabled explicitly. +1. ___ Distutils-SIG maillist

Re: [Distutils] Improving distutils vs redesigning it (was people want CPAN)

On Nov 11, 2009, at 10:04 PM, Robert Kern wrote: In our considered opinion, piecemeal changes probably aren't going to solve the significant problems that we face. At best, they simply aren't going to help; we wouldn't be able to use the new features until we can drop support for Python

Re: [Distutils] Improving distutils vs redesigning it (was people want CPAN)

On Nov 12, 2009, at 12:02 AM, David Cournapeau wrote: Glyph Lefkowitz wrote: There are probably a dozen other ways that you *could* work on distutils and benefit more immediately from your efforts than the next Python release. To think otherwise is a simply a failure of imagination. Now

Re: [Distutils] Improving distutils vs redesigning it (was people want CPAN)

On Nov 12, 2009, at 1:36 AM, Robert Kern wrote: Glyph Lefkowitz wrote: Still, it would have been more helpful to point out how exactly this problem could be solved, (...) Sorry, I edited out the bit at the last minute where I explained that it would be great to have a centralized

Re: [Distutils] People want CPAN :-)

On Nov 6, 2009, at 12:53 PM, Guido van Rossum wrote: I just found this comment on my blog. People have told me this in person too, so I believe it is real pain (even if the solution may be elusive and the suggested solutions may not work). But I don't know how to improve the world. Is the work

Re: [Distutils] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

On Oct 27, 2009, at 7:41 PM, David Lyon wrote: I'm not sure about that Tarek.. An .exe installer as a perfect binary format for python packages? Are you serious? That is the biggest security threat I can think of, asking python users to run unverified, unsigned, un-trusted executable files

Re: [Distutils] setup.cfg new format proposal

try to have the metadata, for real, at all. Here's an example of something I want to be able to do with metadata: from distutils.something import ( load_metadata, pypi_metadata, installed_metadata) meta = installed_metadata(Twisted) meta2 = load_metadata(/home/glyph/Downloads/Twisted-x.y) meta3

Re: [Distutils] how do I add some functionality to my setup.py which is testable and modular?

On Tue, Aug 18, 2009 at 7:20 PM, Zooko Wilcox-O'Hearn zo...@zooko.comwrote: ... and Glyph refuses to accept my patch which fixes it because the fix isn't testable ... Hi, Zooko :). Since this message officially makes me That Jerk Who Is Forcing The Issue, I've finally joined distutils-sig

Re: [Distutils] how do I add some functionality to my setup.py which is testable and modular?

On Sun, Aug 16, 2009 at 8:17 PM, P.J. Eby p...@telecommunity.com wrote: At 02:16 PM 8/16/2009 -0600, Zooko Wilcox-O'Hearn wrote: So it appears to me that none of these techniques are both modular/ testable and compatible with distutils/setuptools/Distribute. What are we to do? We could

[Distutils] [issue67] You can't tell easy_install not to talk to the network

New submission from Glyph Lefkowitz gl...@twistedmatrix.com: If I want to use easy_install for nice dependency resolution, there's no way (that I can figure out, at least) to tell it never talk to the network, use only this local directory where you can find dependencies. -- messages

[Distutils] Why not distutils? (was Re: [Python-Dev] shal we redefine module and package?)

I'm not on distutils-sig, but this is probably of little interest to python-dev. Please Cc: me if you think my continued input would be useful to this discussion. On 08:25 pm, [EMAIL PROTECTED] wrote: almost always in the phrase, please do not use distutils to do a system install of Twisted,

Re: [Distutils] [Python-Dev] shal we redefine module and package?

On 10:53 pm, [EMAIL PROTECTED] wrote: zooko wrote: Unfortunately these answers aren't quite right. A package is actually a directory containing an __init__.py file, and a distribution is actually what you think of when you say package -- a reusable package of Python code that you can, for