Re: [Distutils] Python 3.x Adoption for PyPI and PyPI Download Numbers

On Tue, Apr 21, 2015 at 01:54:55PM -0400, Donald Stufft wrote: > > Anyways, I'll have access to the data set for another day or two before I > shut down the (expensive) server that I have to use to crunch the numbers so > if > there's anything anyone else wants to see before I shut it down, speak

[Distutils] What's the use case of testpypi?

When we locked down pypi to prevent uploading an sdist to overwrite a previous I remember that some people wanted a brief window to check for brown paper bag issues and be able to upload a new tarball in that window if needed. IIRC, those people were told to use testpypi for that sort of thing. U

Re: [Distutils] Add optional password_command .pypirc value

On Fri, Mar 08, 2013 at 12:57:54PM -0500, Donald Stufft wrote: > On Mar 8, 2013, at 12:47 PM, Lennart Regebro wrote: > > > On Fri, Mar 8, 2013 at 6:01 PM, Donald Stufft wrote: > >> I dislike hijacking SSH to tunnel a HTTP protocol over > > > > I'm not sure we have to hijack or tunnel anything.

Re: [Distutils] [issue152] setuptools breaks with from __future__ import unicode_literals in setup.py

On Sat, Jul 06, 2013 at 06:52:05AM +, mbogosian wrote: > > New submission from mbogosian: > > unicode_literals break a bunch of stuff in setuptools. Considering they may > become the default at some point, this should be fixed...? I do not know if > this is related to issue 78. > > To repr

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

Over on python-dev we're talking about Linux Distributions switching from python2 to python3, what steps they need to take and in what order. One of the things that's come up [1]_ is that a very early step in the process is making sure that shebang lines use /usr/bin/python2 or /usr/bin/python3 a

Re: [Distutils] Pycon

On Tue, Apr 01, 2014 at 08:41:12AM +1000, Nick Coghlan wrote: > > On 1 Apr 2014 03:26, "Barry Warsaw" wrote: > > > > 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 wo

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

On Fri, Sep 19, 2014 at 9:26 PM, Richard Jones wrote: > When someone requests to take over a listing on PyPI, the process is: >i > * If the request comes in through some means other than the sf.net support > tracker, I require the requestor to make the request through that tracker so > there is a

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

On Sat, Sep 20, 2014 at 11:34 AM, Donald Stufft wrote: > > > For the record, CPAN and npm both have similar things allowing someone to > take > over an abandoned project. > > I don’t believe ruby gems has an official policy and it appears that they > are hesitant > to do this form the threads I’ve

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

y your email address is often taken from you and, when someone with a similar name or inclination arrives, that address can be given to someone else. > Toshio Kuratomi wrote: >> >> But there are >> also security concerns with letting a package bitrot on pypi. > > > Agai

Re: [Distutils] Disabling --single-version-externally-managed

Phillip J. Eby wrote: > At 01:14 AM 8/29/2007 -0400, Ignacio Vazquez-Abrams wrote: >> I have some packages that I'm using the following with: >> >> %{__python} setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT >> >> I now need to install multiple versions of one of the packages and so >> nee

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 03:26 PM 8/31/2007 -0700, Toshio Kuratomi wrote: >> >> At this point I expect import sqlalchemy to import the 0.4 version and >> pkg_resources to give me access to 0.3.10 or 0.4.0beta4 depending o

Re: [Distutils] Disabling --single-version-externally-managed

[Resending with gzipped complete filelist as the previous try was too large to send to the list] Just to illustrate what I'm trying to achieve. I've updated the Fedora Packaging Guidelines[1]_ to allow two versions of a package to coexist. I'll list here the sqlalchemy-0.4 and -0.3 build steps,

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 06:56 PM 8/31/2007 -0700, Toshio Kuratomi wrote: >> I tried manually creating a .pth file that lists one or the other of the >> eggs. > > That won't work to make the egg the default

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, I found a bug. I haven't coded a solution yet so I don't know precisely what fixing it will do for the rest of our conversation yet:: def insert_on(self, path, loc = None): """Insert self.location in path before its nearest parent d

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 09:20 PM 8/31/2007 -0700, Toshio Kuratomi wrote: >> Just to illustrate what I'm trying to achieve. I've updated the Fedora >> Packaging Guidelines[1]_ to allow two versions of a package to coexis

Re: [Distutils] Disabling --single-version-externally-managed

Toshio Kuratomi wrote: > > This code creates an unordered list because you might have already had > to place something after one of the duplicate locations that this code > is removing. We need to do a sort of the entire list after each add + > duplicate removal run. Here'

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 01:38 PM 9/1/2007 -0700, Toshio Kuratomi wrote: >> I'm seeing an actual problem with this when starting with the following >> sys.path: >> ['/usr/bin', '/usr/lib/python25.zip'

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 02:54 PM 9/1/2007 -0700, Toshio Kuratomi wrote: >> Toshio Kuratomi wrote: >> > >> > This code creates an unordered list because you might have already had >> > to place something after

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 07:45 PM 9/1/2007 -0700, Toshio Kuratomi wrote: >> pkg_resource.requires() is documented on the web page, in >> pkg_resource.txt, and when you python setup.py install >> - --single-version-externally-m

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > > Please, please stop and back up a minute. appreciate your eagerness to > help, really, but right now I can't trust the correctness of the initial > system against which you are performing your tests. You've got crazy > stu

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 11:37 PM 9/1/2007 -0700, Toshio Kuratomi wrote: >> I realize that taken in the vacuum of that single easy_install run, >> require() works. But the instructions are neglecting to tell the user >> that th

Re: [Distutils] Disabling --single-version-externally-managed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 12:49 AM 9/2/2007 -0700, Toshio Kuratomi wrote: >> >> Let me know what else you need. > > What are the current contents of easy-install.pth? > > import sys; sys.__plen = len(sys.path) import s

Re: [Distutils] Why are egg-info and related pth files required for rpm packages?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby wrote: > At 12:39 PM 9/4/2007 -0400, Stanley A. Klein wrote: >> I recently installed Fedora 7 and looked at >> /usr/lib/python2.5/site-packages. The directory has numerous Python >> packages installed but no egg-info and few .pth files.

[Distutils] Patch for minor easy_install problem

It looks like this fix to easy_isntall: ''' 0.6c5 * Fixed .dll files on Cygwin not having executable permisions when an egg is installed unzipped. ''' introduced a minor bug. From 0.6c5 on, installing an egg unzipped makes all the files executable. Attaching a patch that only makes

Re: [Distutils] "Python Package Management Sucks"

Ian Bicking wrote: > Rick Warner wrote: >>> Actually, PyPI is replicated. See, for example, >>> http://download.zope.org/simple/. >>> >>> It may be that some of the mirrors should be better advertised. >> >> A half-hearted effort. at best, after the problems last year. When I >> configure a CPAN

Re: [Distutils] Msgfmt in distutils?

Andrew Price wrote: > Hi, > > Distutils has made my life easier as an python application author and packager > for some time but when it comes to generating and distributing message > catalogues for translations, things get unexpectedly tricky. > > It would be nice to be able to do something like

Re: [Distutils] "Python Package Management Sucks"

You guys are fairly into you debate so hopefully I don't interject something that's already been gone over :-) Chris Withers wrote: > Matthias Klose wrote: Install debian and get back to productive tasks. >>> This is an almost troll-like answer. >>> See page 35 of the presentation. >> >> I di

Re: [Distutils] Question about easy-install.pth

Brian Cameron wrote: > You're actually describing pretty much exactly how rpm works :-) As such, the Fedora Project has had to deal with many of the same issues in packaging python packages as you're running into. This pairs of pages may help you: http://fedoraproject.org/wiki/Packaging/Python

Re: [Distutils] Msgfmt in distutils?

Jeroen Ruigrok van der Werven wrote: > -On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote: >>> and have distutils do the right thing with the .po files at build time >>> (generate .mo files from them) and at install time (install them into >>> PREFIX/

Re: [Distutils] Msgfmt in distutils?

Jeroen Ruigrok van der Werven wrote: > -On [20081001 20:26], Toshio Kuratomi ([EMAIL PROTECTED]) wrote: >> That's good to know. One of our Turbogears applications uses Babel and >> it definitely doesn't install to the right place. I'd love to fix it to >&g

Re: [Distutils] "Python Package Management Sucks"

Phillip J. Eby wrote: > At 11:00 AM 10/1/2008 -0700, Toshio Kuratomi wrote: >> I have no love for how pkg_resources implements this (including the API) >> but the idea of retrieving data files, locales, config files, etc from >> an API is good. For packages to be coded tha

Re: [Distutils] "Python Package Management Sucks"

Phillip J. Eby wrote: > At 09:40 PM 10/1/2008 +0200, Josselin Mouette wrote: >> Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit : >> > > We need to be able to mark locale, config, and data files in >> > >the metadata. >> > >> > Sure... and having a standard for specifying tha

Re: [Distutils] Msgfmt in distutils?

Philip Jenvey wrote: > > On Oct 1, 2008, at 11:25 AM, Toshio Kuratomi wrote: > >> Jeroen Ruigrok van der Werven wrote: >>> -On [20081001 16:28], Toshio Kuratomi ([EMAIL PROTECTED]) wrote: >>>>> and have distutils do the right thing with the .po files at bu

Re: [Distutils] "Python Package Management Sucks"

Dave Peterson wrote: > Josselin Mouette wrote: >> Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit : >> >>> To be clear, I mean here that a "file" (as opposed to a resource) is >>> something that the user is expected to be able to read or copy, or >>> modify. (Whereas a resou

Re: [Distutils] "Python Package Management Sucks"

Phillip J. Eby wrote: > At 03:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote: >> resources, as I said needs to be defined. You're saying here that a >> resource is something internal to the library. A "file" is something >> that a user can read, copy, or modify.

Re: [Distutils] "just use debian"

David Cournapeau wrote: > Josselin Mouette wrote: >> Indeed, and the reason is that *functions never disappear from the >> glibc*. > > Yes and no. If you remove a function, you're indeed screwed, because you > can't handle versioning in the header. But you can handle versioning in > libraries at t

Re: [Distutils] "Python Package Management Sucks"

Greg Ewing wrote: > Toshio Kuratomi wrote: > >> this is what I was afraid of. This is definitely not a definition >> of resource-only that has meaning for Linux distributions. None of the >> data in /usr/share is user-modifiable > > In that case it must be t

Re: [Distutils] "just use debian"

David Cournapeau wrote: > Toshio Kuratomi wrote: >> I'm not 100% certain but I think that Josselin is speaking of glibc in >> particular here and you're speaking of c libraries in general. > > Maybe, but I don't see how this change the point: when you change

Re: [Distutils] "Python Package Management Sucks"

Phillip J. Eby wrote: > At 07:14 PM 10/1/2008 -0700, Toshio Kuratomi wrote: >> In terms of implementation I'd much rather see something less centered >> on the egg being the right way and the filesystem being a secondary >> concern. > > Eggs don't have an

Re: [Distutils] pre-PEP : Synthesis of previous threads, and irc talks + proposals

zooko wrote: > On Oct 1, 2008, at 19:10 PM, Tarek Ziadé wrote: > >> I hate the idea of dynamic metadata in fact. I can't express precisely >> why at that point. > > Me too and me too. > > Perhaps it would help to distinguish between requiring a certain > functionality and requiring a specific co

Re: [Distutils] Pre-pre-PEP: Requirements for the Python BUILDS Specification

Ian Bicking wrote: > Paul Moore wrote: >> My feeling, by the way, is that "system packagers" are the more >> relevant group on Linux/Unix (where most users install Python modules >> via system packages, or else they are developers) > > I think this is part of why I don't understand the system pack

Re: [Distutils] [Catalog-sig] distribute D.C. sprint tasks

Martin v. Löwis wrote: >> Right, please take a look at my last version >> http://wiki.python.org/moin/PEP_374 >> it tries to go in that direction > > For such an infrastructure (which apparently intends to mirror the files > as well), I insist that a propagation of download counters is made > man

[Distutils] Symlinks vs API -- question for developers

So I have a question for all the developers on this list. Philip thinks that using symlinks will drive adoption better than an API to access package data. I think an API will have better adoption than a symlink hack. But the real question is what do people who maintain packages think? Since Phi

Re: [Distutils] Fixing the mess in sdist/egg_info

Tarek Ziadé wrote: > Hi, > > I am back on that problem with the code that builds the file list. The > current Distutils trunk isn't working anymore with setuptools because > of a recursive loop: > > distutils.sdist.run() -> setuptools.build_py.data_files -> > setuptools.egg_info.run() -> distutil

Re: [Distutils] Making commands extensible by default

Tarek Ziadé wrote: > Hello, > > This is a side discussion but quiet important ihmo. > > == Problem == > > Some people complained about the fact that is was hard to extend > Distutils commands. > You end up rewriting the whole command most of the time. > > So what's a command ? It's a class that

Re: [Distutils] Making commands extensible by default

David Cournapeau wrote: > Toshio Kuratomi wrote: >> Tarek Ziadé wrote: >> >>> Hello, >>> >>> This is a side discussion but quiet important ihmo. >>> >>> == Problem == >>> >>> Some people complained about the fact t

Re: [Distutils] Making commands extensible by default

David Cournapeau wrote: > Toshio Kuratomi wrote: >> They don't have bearing on talking about >> redesigning how to design a new architecture that's easy to extend. >> > > Those examples show why extending distutils commands with subclassing + > post

Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata

On Thu, Oct 08, 2009 at 12:39:33PM -0400, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey all, > > I propose adding a bit to the PEP 376 metadata that indicates whether a > package was installed by user request or as a dependency of another > package. This would allow

Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata

On Thu, Oct 08, 2009 at 03:41:44PM -0400, Carl Meyer wrote: > > Also note that a package manager should be able to tell required status from > > what is currently installed. So it might make more semantic sense to record > > what was requested by the user to be installed instead of what was requir

Re: [Distutils] Packaging Distribute

On Thu, Oct 08, 2009 at 11:07:13PM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > 2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a): > > On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé > > wrote: > > > > > The other way would be to use Distribute instead of Setuptools for > > > what the p

Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata

On Fri, Oct 09, 2009 at 09:21:29AM -0400, Carl Meyer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Chris Withers wrote: > The downside here is that it introduces one more wrinkle for installers > to worry about handling correctly. There are strong use cases for the > single bit "req

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote: > > In this case, which I suspect is extremely rare anyway, you'll need to > have setuptools installed already. > > So, in *any* of these cases, specifying setuptools as a requirement > seems like a total waste of time... > > Now, w

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote: > Toshio Kuratomi wrote: >> On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote: >>> In this case, which I suspect is extremely rare anyway, you'll need >>> to have setuptools installed

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

On Fri, Oct 09, 2009 at 05:13:16PM +0100, Chris Withers wrote: > Toshio Kuratomi wrote: >> On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote: >>> Toshio Kuratomi wrote: >>>> On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote: >>>>&g

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

On Tue, Oct 20, 2009 at 02:48:58PM +0100, Chris Withers wrote: > Fred Drake wrote: >> On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers >> wrote: >>> As is specifying the setuptools distribution as a requirement when you're >>> already using it... >> >> I don't use setuptools at runtime unless somet

Re: [Distutils] Looking for portable what to determine directory where extensions are installed?

On Wed, Nov 11, 2009 at 09:46:25AM -0800, Tom Epperly wrote: > > I thought distutils.sysconfig.get_python_lib() might be helpful, but it > returns "/usr/lib/python2.6/site-packages" even on the system where > "/usr/lib64/python2.6/site-packages" is the right answer. > You're on the right track here

Re: [Distutils] PEP 386 status - last round here ?

Many many things in this thread Unfortunately, there's so many ways to do versioning that it's almost a bikeshed topic and so there's a lot of different ideas of what could be right. Let me start by saying what I think is "right" and then the rest of my message will be devoted to what things s

Re: [Distutils] PEP 386 status - last round here ?

On Sat, Nov 28, 2009 at 04:27:04PM +0100, Tarek Ziadé wrote: > On Fri, Nov 27, 2009 at 8:55 PM, Toshio Kuratomi wrote: > [lots of explanation] > > Thanks for these explanations Toshio. I am starting to think that > whatever we use on Python side will be fine for you guys, (a

Re: [Distutils] Common version-comparison semantics for peace love and harmony

On Sat, Nov 28, 2009 at 05:07:01PM +0100, Tarek Ziadé wrote: > > So If the current proposal works for all cases (e.g. people can > translate their schemes > into PEP 386 one), I am proposing to: > > 1- reject the "+", " ", "-" proposal, and stick with "." so we have > only one way to express the

Re: [Distutils] PEP 386 status - last round here ?

On Thu, Dec 03, 2009 at 01:55:53PM +0100, M.-A. Lemburg wrote: > Tarek Ziadé wrote: > > Last, as I said in a previous mail, I tend to agree with the people > > who said that we should stick with only one way to write the version > > scheme for the sake of clarity. e.g. dropping aliases and picking

Re: [Distutils] Recent buildout failure in Mailman 3

On Mon, Oct 11, 2010 at 11:46:11AM -0400, Barry Warsaw wrote: > On Oct 08, 2010, at 11:37 PM, P.J. Eby wrote: > > >At this point, I'm a bit stumped, as I don't know enough about how tarballs > >are supposed to work internally; should I just whip up a patch for the > >situation where the path has n

Re: [Distutils] zc.buildout and "System Python"

On Thu, Oct 28, 2010 at 10:22:58AM -0400, Jim Fulton wrote: > > It occurs to me that it would be nice if we made clean Python > packages available for some of the popular Unix platforms. I'm not > sure what would be involved in doing that, from a distribution point > of view. > If you're

Re: [Distutils] zc.buildout and "System Python"

On Thu, Oct 28, 2010 at 12:08:30PM -0400, Jim Fulton wrote: > On Thu, Oct 28, 2010 at 11:47 AM, Toshio Kuratomi wrote: > > On Thu, Oct 28, 2010 at 10:22:58AM -0400, Jim Fulton wrote: > >> > >>   It occurs to me that it would be nice if we made clean Python > >&

Re: [Distutils] Preventing downloading for package requirements

On Wed, Feb 23, 2011 at 10:04:24PM +0100, Tarek Ziadé wrote: > > > > One way that seems to work is to add this to setup.cfg: > > > > [easy_install] > > allow_hosts: www.example.com > > > > This will break the download by limiting acceptable hosts to bogus ones that > > can't possibly satisfy the re

Re: [Distutils] Distribute and Python 3.2

On Sat, Mar 12, 2011 at 11:05:50AM +, Vinay Sajip wrote: > > P.S. IMO Toshio Kuratomi's fix could be better implemented as > > self.config_vars['abiflags'] = getattr(sys, 'abiflags', '') > > in the same block as all the other self.config_vars[...] assignments. > Committed as: diff -r f64c2

Re: [Distutils] Proposal: drop md5 for sha256

On Tue, Jul 03, 2012 at 06:33:08PM -0500, Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: > On hosts configured for compliance with U.S. Federal Information > Processing Standard (FIPS) 140-2 > , like > those in some banks and, yes, t

Re: [Distutils] Differences in PEP386 and setuptools

On Wed, Sep 26, 2012 at 03:09:19PM -0400, Donald Stufft wrote: > I've been comparing how PEP386/distutils2.version treats versions > and how pkg_resources from setuptools treats versions and it > confirmed a worry of me with the way that dev is treated in PEP386. > > In PEP386 you have several kin

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, Sep 27, 2012 at 09:25:51AM -0400, Donald Stufft wrote: > On Thursday, September 27, 2012 at 9:12 AM, Erik Bray wrote: > > My guess--and this is pure speculation as I wasn't following the > original discussions either--is that it fell out of the desire to > require versions to b

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, Sep 27, 2012 at 01:00:10PM -0400, Donald Stufft wrote: > On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote: > > I would be for renaming .dev to .pre[1]_ but I would be against the rest > of > this > proposal. Having one and only one way t

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, Sep 27, 2012 at 01:46:25PM -0400, Éric Araujo wrote: > Le 27/09/2012 11:59, Toshio Kuratomi a écrit : > > * a, b, c, and rc are the typical alpha beta release candidate tags. We > > debated whether to allow the single letter versions or the long versions > > "

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, Sep 27, 2012 at 02:42:50PM -0400, Donald Stufft wrote: > > On Thursday, September 27, 2012 at 2:03 PM, Toshio Kuratomi wrote: > > That's your preference, not capability. I'd also say you should use > 1.0.post1 rather than 1.0a1pre1. > > So h

Re: [Distutils] Differences in PEP386 and setuptools

On Thu, Sep 27, 2012 at 05:00:56PM -0500, Brad Allen wrote: > On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi wrote: > > > However, now that you mention it, ISTR that this is the way that it was > > originally and the lack of pre/dev in that position did bother another (se

Re: [Distutils] Panel on packaging at PyCon 2013

On Fri, Sep 28, 2012 at 12:08:48PM -0400, Barry Warsaw wrote: > On Sep 28, 2012, at 12:01 PM, Éric Araujo wrote: > > >I’m putting up a last-minute proposal for a panel about directions for > >the packaging ecosystem at the next PyCon. For that I would need a list > >of panelists. I think it woul

Re: [Distutils] Changing the separator from - to ~ and allow all Unicode alphanumerics in package names...

On Fri, Nov 09, 2012 at 09:38:54PM -0500, Daniel Holth wrote: > Although I think the ~ is a very ugly -, it could be useful to change the > separator to something less commonly used than the -. > > It would be useful to be able to use the hyphen - in the version of a package > (for semver) and els

Re: [Distutils] Changing the separator from - to ~ and allow all Unicode alphanumerics in package names...

On Mon, Nov 12, 2012 at 02:34:14PM -0500, Daniel Holth wrote: > > > Horrifying. All codecs that are not utf-8 should be banned, except on Windows. > I made that argument on python-dev but it didn't win the necessary people over. I don't recall why so you'd have to look at the thread to see wha