OK, Gerry, I have addressed your concerns.
1) Note that the release number is still squelched in the case of RPMs
compiled from SVN checkouts of distutils packages. This is so that alpha,
beta or release candidate packages can upgrade SVN checkouts without extra
intervention from the packager.
At 02:17 AM 3/13/2009 +0100, Brian Sutherland wrote:
http://pypi.python.org/pypi/van.potomo/
However, one major problem is that to modify the function of the
setup.py "build" and "develop" commands one needs to do this in the
setup.py:
from setuptools import setup, find_packages
fr
OK, now we're talking. You have given me a test case that makes my patch fail
and I will address it after How I Met Your Mother.
El Jueves 12 Marzo 2009, Gerry Reno escribió:
> Manuel,
> In RPM the only restriction on 'version' is that it must be made of
> alphanumeric or period. Ref:
> http:
Manuel,
In RPM the only restriction on 'version' is that it must be made of
alphanumeric or period. Ref:
http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-tags.html
Just for a small test I ran a perfectly legal version pattern, that is
allowable in distros other than Fedora, through your pat
> That is the ONLY policy there is for Mandriva. So, if you like, then
> you can say the policy is whatever 'version' and 'release' naming that
> will work in an RPM spec file. And that's way more flexible than
> Fedora's policy.
If the policy is "whatever works", then my patches comply with the
Manuel Amador (Rudd-O) wrote:
> Mandriva link: http://wiki.mandriva.com/en/Policies/RpmSpecProposal
Thanks for providing the link. Which is a PROPOSAL, not a polcy. On a
user-editable WIKI. And on top of that, what you say about versioning
style is in NO WAY backed by that document.
That is t
Hi,
I've just released a setuptools/distutils extension that makes the
process of compiling translations (i.e. .po -> .mo files) quite
automatic.
http://pypi.python.org/pypi/van.potomo/
However, one major problem is that to modify the function of the
setup.py "build" and "develop" commands o
> Mandriva link: http://wiki.mandriva.com/en/Policies/RpmSpecProposal
Thanks for providing the link. Which is a PROPOSAL, not a polcy. On a user-
editable WIKI. And on top of that, what you say about versioning style is in
NO WAY backed by that document.
Now we know for a fact that my patch
Manuel Amador (Rudd-O) wrote:
El Miércoles 11 Marzo 2009, Gerry Reno escribió:
> Ok, Mandriva comes to mind. It's policy is different and allows more
> flexibility than Fedora's.
Well, would you be so kind to link the Mandriva policy for us to read
about it?
Mandriva link: http://wiki.mand
El Miércoles 11 Marzo 2009, Gerry Reno escribió:
> Ok, Mandriva comes to mind. It's policy is different and allows more
> flexibility than Fedora's.
Well, would you be so kind to link the Mandriva policy for us to read about
it?
>
> Besides, policies are meant for humans. And policies change.
On Wed, Mar 11, 2009 at 11:09:03PM -0700, Garrett Cooper wrote:
> Also, has any serious thought been put into maybe taking the package
> name, producing specific mnemonic based .pth files for the particular
> package, and just installing this way, e.g.:
>
> pexpect -> pexpect.pth
> nose -> nose.pt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
> Jim Fulton wrote:
>> On Mar 12, 2009, at 8:47 AM, Tres Seaver wrote:
>> ...
>>> I'm doing most of my development these days with Python 2.6, and would
>>> like to get a deprecation-warning-free version of zc.buildout released
>>> i
Please add the "Framework :: Setuptools Plugin" classifier to your
metadata so that setuptools_hg will appear on this search:
http://pypi.python.org/pypi?:action=browse&c=524
Done, thanks!
Best,
Jannis
___
Distutils-SIG maillist - Distutils-SIG@p
On Thu, Mar 12, 2009 at 19:02, P.J. Eby wrote:
> In which case, either separate source distros are required
Which I would like to avoid.
> or 2to3 will need to be present
It is, as it's included with Python.
> and the main setup.py will need to detect python3 and
> run 2to3 on itself, then exe
At 06:20 PM 3/12/2009 +0100, Lennart Regebro wrote:
I don't have many assumptions. I just want the setuptools install and
tests to work as expected under both python2 and python3. And that
means that python3.0 setup.py install should work. And python3.0
setup.py test would be nice too, although
On Thu, Mar 12, 2009 at 17:51, P.J. Eby wrote:
> I'm not aware anyone was arguing.
OK, wrong word "explaining" then. :)
> I've suggested that
> perhaps my assumption that both the 2.x and 3.x interpreters are available
> was the one we don't share, but you didn't comment on that.
I though I did
I note that there still isn't a win32 version of the setuptool installer for
python 2.6. Is this in the works? For those who do not have VC++ 2008, it
is tricky to get setuptools installed. I have built the .exe myself (and
could provide it to you if you wanted), but I wondered why, after all th
At 08:38 AM 3/12/2009 +0100, Lennart Regebro wrote:
On Thu, Mar 12, 2009 at 08:35, Lennart Regebro wrote:
> On Thu, Mar 12, 2009 at 03:38, P.J. Eby wrote:
>> That's not a catch 22. You simply run a 2.x setup.py with options that
>> cause the conversion to take place before running 3.x over the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
> On Mar 12, 2009, at 8:47 AM, Tres Seaver wrote:
> ...
>> I'm doing most of my development these days with Python 2.6, and would
>> like to get a deprecation-warning-free version of zc.buildout released
>> if possible for the project
I stumbled on the "Googling for setuptools plus Mercurial leads to
an outdated plugin" problem the other day. I e-mailed the author
and asked him to update the page with a link to setuptools_hg, but
haven't gotten response yet. Alternatively, people could give a nod
to setuptools_hg with a
On Mar 12, 2009, at 8:47 AM, Tres Seaver wrote:
...
I'm doing most of my development these days with Python 2.6, and would
like to get a deprecation-warning-free version of zc.buildout released
if possible for the projects which use buildout.
OK
I would be glad to make the release myself, if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm doing most of my development these days with Python 2.6, and would
like to get a deprecation-warning-free version of zc.buildout released
if possible for the projects which use buildout.
I would be glad to make the release myself, if desired: jus
On Thu, Mar 12, 2009 at 08:35, Lennart Regebro wrote:
> On Thu, Mar 12, 2009 at 03:38, P.J. Eby wrote:
>> That's not a catch 22. You simply run a 2.x setup.py with options that
>> cause the conversion to take place before running 3.x over the converted
>> result. Now you have a 3.x version.
>
>
On Thu, Mar 12, 2009 at 03:38, P.J. Eby wrote:
> That's not a catch 22. You simply run a 2.x setup.py with options that
> cause the conversion to take place before running 3.x over the converted
> result. Now you have a 3.x version.
How do you run this? What is the command you would use?
--
L
24 matches
Mail list logo
