other folks are maintaining Distribute now. I cc'ed him and
distutils@
Thanks
Tarek
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 3/14/13 9:49 AM, Tarek Ziadé wrote:
Congrats,
This is a good move for packaging. I am very glad the merge is
happening, knowing that it's now managed by a community of contributors.
Cheers
Tarek
Oh btw, I was told Philip was saying in private he was agreeing to do
the merge as long as I
Congrats,
This is a good move for packaging. I am very glad the merge is
happening, knowing that it's now managed by a community of contributors.
Cheers
Tarek
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist
know guys I have initially created this project in a GSOC for a
future Distutils integration ? That was the primary use case
so +1 :)
Cheers
Tarek
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist - Distutils-SIG@python.org
and once it's
working, add a permanent redirect on the old address
That'll also take care of the bad uptimes I have on my cheap server
Any concerns ?
Cheers
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist - Distutils
On 2/14/13 6:32 PM, Jim Fulton wrote:
On Thu, Feb 14, 2013 at 11:41 AM, Tarek Ziadé ta...@ziade.org wrote:
Hey
As Marc-André suggested, it would be a good thing to move the bootstrapping
file to
:https://pypi.python.org/packages/source/d/distribute/distribute_setup.py
+1
I need to do
is to tweak release.py so it does a POST if
the file using the user in .pypirc
I can isolate that feature, as I said in the previous mail
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
On 1/28/13 7:17 AM, Nick Coghlan wrote:
...
3. There needs to be a mechanism to inform automated tools of the
*right* version ordering to use, with PEP 386 being the default.
what happens when you compare two versions from two different schemes ?
Cheers
Tarek
--
Tarek Ziadé · http
/distribute_setup.py
Maybe it would be smarter to have it in a more reliable place - and with
more people being able to manage it.
Does anyone have a good idea for this ? If someone has a better solution
I can redirect the domain to a new place.
Thanks
Tarek
--
Tarek Ziadé · http://ziade.org
.
+ accept the CNAME redirect
Cheers
Tarek
--
Tarek Ziadé · http://ziade.org · @tarek_ziade
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Hey
I was reading this :
http://distlib.readthedocs.org/en/latest/overview.html#what-was-the-problem-with-packaging
and I thought I should bring up that distutils2 has implemented a way to
define data files that can be installed in the right places on the
target system. right here being
On 11/18/12 10:15 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
and I thought I should bring up that distutils2 has implemented a way to
define data files that can be installed in the right places on the
target system. right here being what the linux distros decides
On 11/18/12 11:15 PM, Chris McDonough wrote:
On 11/18/2012 05:08 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
Having a indirection like distutils2's resources allows the data files
to live alongside the code
in development and to be installed wherever that's desired
On 11/18/12 11:25 PM, Antonio Cavallo wrote:
Just come to my mind data test related to a package would be a natural
candidate:
mypack
|- __init__.py
|- test
|- __init__.py
|- test0.py
|- data
|- data.for.test0.dat
It is natural deploying them
On 11/18/12 11:45 PM, Chris McDonough wrote:
I don't really take exception to having such a feature (although I
would be unlikely to use it), but I do take exception to the first
paragraph of the description you pointed at:
This section describes the files used by the project which must not
On 10/5/12 12:28 AM, Vinay Sajip wrote:
I've updated distlib as follows:
1. I've added support for the equivalent of pkg_resources.resource_filename
for returning a true filesystem path for a resource. I've added info about
this in the Distlib's design document, though the reference API
On 10/5/12 12:19 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
I like the idea of having a main section to play with the tools, people
can invoke with -m
I don't think its a bad idea to have it in each module, like what Python
does
for SimpleHTTPServer or json.tools
I've
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I don't think you can copyright them under your name like what I have
seen in setup.py
AFAIK I've only
On 9/27/12 4:22 PM, Paul Moore wrote:
On 27 September 2012 15:01, Tarek Ziadé ta...@ziade.org wrote:
I think it's perfectly fine to have hg.python.org/distlib and do what you
described.
It can mature there - it does not bother cpython or other repositories.
One advantage of distlib being
On 9/27/12 4:40 PM, Paul Moore wrote:
(Sorry, meant to post to the list)
On 27 September 2012 15:26, Tarek Ziadé ta...@ziade.org wrote:
But then, unless I am mistaken, you have to ask each contributor to sign the
agreement to avoid any issue the day it goes into Python.
TBH, I'm not sure
On 9/27/12 4:28 PM, Antoine Pitrou wrote:
Le jeudi 27 septembre 2012 à 16:01 +0200, Tarek Ziadé a écrit :
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé tarek at ziade.org writes:
On a side note, since these are the original modules that were taking
out of Python's packaging
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that might one day become part of Python. OTOH
On 9/27/12 6:37 PM, Georg Brandl wrote:
On 09/27/2012 05:49 PM, Tarek Ziadé wrote:
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé tarek at ziade.org writes:
There are two of us maintaining hg.python.org: Georg and I. So, I
don't
know about Georg, but I don't want to maintain
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
Last but not least, distlib is the plan forward endorsed by python-dev,
Is it? I haven't seen a PEP or an official decision about that. Just because
someone proposed it on a mailing-list doesn't mean it is endorsed by
python-dev.
We discussed about
On 9/23/12 5:57 PM, Vinay Sajip wrote:
I've updated distlib[1] with a resources API - functionality for accessing data
files co-located with code in Python packages. This is missing from the stdlib
and currently people use pkg_resources to achieve this.
The design and implementation allows for
On 9/13/12 10:15 AM, Chris McDonough wrote:
Some packages we maintain currently provide largely identical
side-by-side implementations of features: one implementation is written
in C, the other implementation is written in Python. The C module is
just an optimized version of the Python code.
On 9/11/12 9:56 PM, Donald Stufft wrote:
On Tuesday, September 11, 2012 at 3:36 PM, Tarek Ziadé wrote:
We need to fix PEP 386 though
On the topic of PEP386, It also doesn't specify how versions like 2.5
and 2.5.0
should be treated. That's what originally got me on the thread of how
PEP345
On 9/13/12 3:21 AM, SAn wrote:
On Wed Sep 12 19:47:39 CEST 2012, Donald Stufft wrote:
On Wednesday, September 12, 2012 at 1:43 PM, Erik Bray wrote:
That said, this doesn't match my workflow at all. After releasing
1.0 the next version is going to be 1.1, and any development
pre-release will be
On 9/13/12 9:26 AM, Chris McDonough wrote:
I propose an extension to PEP 376 to support the development of projects
such that:
Since PEP 376 is accepted, we'll need a new PEP for this kind of addition.
- Installation tools should expect to need to cope with files
present in purelib named
On 9/13/12 10:55 AM, Tarek Ziadé wrote:
...
Now what if I am not sudoer ? how can I have the develop feature
without being able to
write develop.pth in purelib ?
Could we find a way to have a per-user *and/or* per local project
directory, that get
scan by Python at startup ?
On a second
On 9/11/12 9:25 PM, Erik Bray wrote:
...
But you could still release 2.5.1.0.0? I suppose we limit the number
of version parts these days.
Why don't we update the spec so that (2.0) means (2.0) the range, and
(==2.0) means 2.0 (exactly).
Daniel
The PEP is ambiguous on this, but you could get
On 9/11/12 9:34 PM, Daniel Holth wrote:
On Tue, Sep 11, 2012 at 3:31 PM, Tarek Ziadé ta...@ziade.org wrote:
On 9/11/12 9:25 PM, Erik Bray wrote:
...
But you could still release 2.5.1.0.0? I suppose we limit the number
of version parts these days.
Why don't we update the spec so that (2.0
On 7/25/12 3:33 PM, Daniel Holth wrote:
I'm happy with markerlib, my implementation of environment markers. In
markerlib, a marker is a function
def marker(environment=None, override=None)
where environment is the environment and override updates the
environment; if environment is None then
On 7/4/12 2:50 AM, PJ Eby wrote:
On Tue, Jul 3, 2012 at 7:33 PM, Jennings, Jared L CTR USAF AFMC 46
SK/CCI jared.jennings@eglin.af.mil
mailto:jared.jennings@eglin.af.mil wrote:
On hosts configured for compliance with U.S. Federal Information
Processing Standard (FIPS) 140-2
On 7/4/12 9:35 AM, Tarek Ziadé wrote:
On 7/4/12 2:50 AM, PJ Eby wrote:
On Tue, Jul 3, 2012 at 7:33 PM, Jennings, Jared L CTR USAF AFMC 46
SK/CCI jared.jennings@eglin.af.mil
mailto:jared.jennings@eglin.af.mil wrote:
On hosts configured for compliance with U.S. Federal Information
On 7/4/12 9:47 AM, Tarek Ziadé wrote:
Oh let's do a fletcher checksum ! This one should be universally
authorized by any system
Better version:
http://tarek.pastebin.mozilla.org/1690480
takes 4 seconds on my MBA for a 40 mb file, so it seems fast enough
since our PyPI limit is 8 Mb
On 7/3/12 3:16 AM, Daniel Holth wrote:
I would like to amend the spec. The hash column of RECORD should be
'sha256:' + urlsafe_b64encode(hashlib.sha256(data))
instead of the hopelessly obsolete md5. With a secure hash function,
you can digitally sign RECORD.
The goal of the RECORD file is to
On 7/1/12 8:50 PM, Marcus wrote:
FWIW I have started a pypi2rpm project that creates RPM out of
PyPI projects, we use at Mozilla to deploy our apps,
http://pypi.python.org/pypi/pypi2rpm
It's just a glue script on the top of an isolated bdist_rpm
command and
On 7/3/12 9:42 AM, Bohuslav Kabrda wrote:
- Original Message -
I would like to amend the spec. The hash column of RECORD should be
'sha256:' + urlsafe_b64encode(hashlib.sha256(data))
instead of the hopelessly obsolete md5. With a secure hash function,
you can digitally sign RECORD.
On 7/3/12 9:44 AM, Donald Stufft wrote:
On Tuesday, July 3, 2012 at 3:42 AM, Tarek Ziadé wrote:
I have also added a proxy that returns a 404 when pip tries to hit
the net, to simulate the --allow-hosts option easy_install has.
I hate this particular misfeature of python packaging.
http
On 7/3/12 9:48 AM, Donald Stufft wrote:
On Tuesday, July 3, 2012 at 3:45 AM, Tarek Ziadé wrote:
Hash in the RECORD file have nothing to do with making sure the package
is originated from developer X.
Its only purpose is to know if a file on the system was changed
Using sha256 would enable
On 7/3/12 9:51 AM, Donald Stufft wrote:
On Tuesday, July 3, 2012 at 3:48 AM, Tarek Ziadé wrote:
Not sure how http://restricted.crate.io/ qorks (unreachable for me
right now - 'internal server error')
Hmm that's odd, it works for me now and I don't see anything logged.
The 3rd hit worked
On 7/3/12 10:05 AM, Alexis Métaireau wrote:
Le mar. 03 juil. 2012 09:55:06 CEST, Tarek Ziadé a écrit :
On 7/3/12 9:51 AM, Donald Stufft wrote:
On Tuesday, July 3, 2012 at 3:48 AM, Tarek Ziadé wrote:
Not sure how http://restricted.crate.io/ qorks (unreachable for me
right now - 'internal
On 7/3/12 10:12 AM, Alexis Métaireau wrote:
Le mar. 03 juil. 2012 10:08:07 CEST, Tarek Ziadé a écrit :
Yeah so even a 'cleaned up' mirror will not do the trick. For pip and
easy_install, we need a lower-level barrier to avoid hitting the net
Well, if links are removed from the indexes
On 7/3/12 4:32 PM, PJ Eby wrote:
On Tue, Jul 3, 2012 at 8:48 AM, Jeroen Dekkers jer...@dekkers.ch
mailto:jer...@dekkers.ch wrote:
And yes, attacks on md5 will only get better, so we should migrate to
better hashes in the future.
No, because that's not what the RECORD hashes are
On 7/3/12 3:54 PM, Daniel Holth wrote:
I'm going to implement this except I will replace the sha256: with a
sha256= There is simply no realistic drawback.
I am -1000 for any change to the RECORD file hashes in PEP 376 unless
there's a clear use case.
Strong hashing is a
prerequisite for
On 6/26/12 8:56 AM, Bohuslav Kabrda wrote:
Hi all,
I recently came upon Tarek's blogpost [1] about converting Python packages to
rpm specfiles. I have pretty good knowledge of this, as I am a Fedora package
maintainer and Python is one of my main responsibilities. I have always wanted
to
On 6/26/12 1:23 PM, Bohuslav Kabrda wrote:
[...]
Exactly, my project is aimed at creating just the specfiles. In Fedora (and other distros
as well), there is a review process that each package must go through and having a
specfile written according to the current guidelines is a necessary part
On 6/25/12 1:11 AM, Jim Fulton wrote:
https://bitbucket.org/tarek/distribute/issue/289/distribute-broken-with-python-33
I'm gonna try to work around it in buildout 2 by monkey-patching
distribute.
Jim
If you write the fix, maybe you can do it against Distribute ? we can
release it right
On 6/25/12 12:57 PM, Jim Fulton wrote:
On Mon, Jun 25, 2012 at 2:53 AM, Tarek Ziadé ta...@ziade.org wrote:
On 6/25/12 1:11 AM, Jim Fulton wrote:
https://bitbucket.org/tarek/distribute/issue/289/distribute-broken-with-python-33
I'm gonna try to work around it in buildout 2 by monkey-patching
On 5/23/12 8:16 AM, Robert Park wrote:
On Mon, May 21, 2012 at 3:42 PM, Tarek Ziadéta...@ziade.org wrote:
If you are a packager for a project, you can describe in details your data
files, and add more metadata that are understood by PyPI.
If you are a debian packager, you will be able to
On 5/16/12 7:35 PM, Mark Sienkiewicz wrote:
Can you see packaging as a set of utility at this point, rather than
a tool that's going to replace instantly all the legacy tools ?
If it is not going to replace the legacy tools, then why should I use it?
Who are you ?
If you are a user that
On 5/16/12 3:58 AM, Chris McDonough wrote:
On 05/15/2012 04:39 PM, Éric Araujo wrote:
Hi again,
Le 01/05/2012 14:28, Paul Moore a écrit :
On 1 May 2012 17:40, Chris McDonoughchr...@plope.com wrote:
Is there a PEP for the packaging package? Is there any sort of
unfinished
business I can help
On 5/16/12 5:01 AM, Alex Clark wrote:
Hi,
On 5/15/12 9:58 PM, Chris McDonough wrote:
On 05/15/2012 04:39 PM, Éric Araujo wrote:
Hi again,
Le 01/05/2012 14:28, Paul Moore a écrit :
On 1 May 2012 17:40, Chris McDonoughchr...@plope.com wrote:
Is there a PEP for the packaging package? Is there
On 5/16/12 3:58 AM, Chris McDonough wrote:
Adding two more (packaging and distutils2) which are similarly
semi-documented and which don't even solve the problems that the
previous ones do would serve no purpose, and baking them into Python
itself will mean they can't evolve in important ways.
On 5/16/12 9:40 AM, Paul Moore wrote:
On 16 May 2012 07:55, Tarek Ziadéta...@ziade.org wrote:
I'd suggest you list what you can't do with packaging today and we work
through that list to point which features are missing and should be
developed *outside* the standard lib, and which ones are in
Taking off Guido, I don't think he needs to be in the whole thread
On 5/16/12 10:30 AM, Paul Moore wrote:
I'm happy to summarise this on there. Let me know a link to the wiki
page.
I created http://wiki.python.org/moin/Packaging/Roadmap
But 2 points:
1. Binary distributions is *not* a
On 5/16/12 3:19 PM, Jim Fulton wrote:
On Wed, May 16, 2012 at 2:55 AM, Tarek Ziadéta...@ziade.org wrote:
On 5/16/12 3:58 AM, Chris McDonough wrote:
Adding two more (packaging and distutils2) which are similarly
semi-documented and which don't even solve the problems that the previous
ones do
On 5/13/12 8:45 PM, Chris McDonough wrote:
On 05/01/2012 12:40 PM, Chris McDonough wrote:
Georg Brandl was trying to herd cats on outstanding PEPs today:
http://mail.python.org/pipermail/python-dev/2012-May/119157.html
Is there a PEP for the packaging package? Is there any sort of
unfinished
On 3/13/12 7:50 PM, Carl Meyer wrote:
On 03/13/2012 05:18 PM, Jim Fulton wrote:
[snip]
1) setuptools eggs
- Have to support legacy meta-data format
2) bdist
- Need to add python version for:
- compatibility info
- also provides delimeter between version # and platform
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
it and try again with the --user option
HTH
Tarek
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
here :
https://bitbucket.org/tarek/distribute/issues
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
/distutils-sig
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG
am, Tarek Ziadé wrote:
On Thu, Nov 10, 2011 at 10:04 AM, Paul Nasrat pnas...@gmail.com wrote:
I don't think bdist_rpm should track vendor packaging requirements,
purely as those recommendations may change faster than the release
process of distutils. I also believe bdist_rpm may be going away
I have sent that to the PSF list because there's a PSF project about PyPI infra.
But someone complained, saying that I was doing this discussion
behind closed doors
SInce this is not my goal, I am now spamming more lists...
-- Forwarded message --
From: Tarek Ziadé ziade.ta
On Tue, Sep 27, 2011 at 12:07 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Sep 27, 2011 at 11:40, Tarek Ziadé ziade.ta...@gmail.com wrote:
1/ stability and high availability
How are opinions on setting up country-specific PyPI mirrors? The lag
to the US is pretty severe in Poland
2011/9/27 Jim Fulton j...@zope.com:
On Tue, Sep 27, 2011 at 6:07 AM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Sep 27, 2011 at 11:40, Tarek Ziadé ziade.ta...@gmail.com wrote:
1/ stability and high availability
How are opinions on setting up country-specific PyPI mirrors? The lag
to complain afterwards about us suffering of some kind of NIH :)
If you're seeing anything you don't like in PEP 381 (accepted a while
ago), go ahead and propose some improvements.
But please keep in mind that we've looked at other systems before we
wrote that PEP.
Cheers
Tarek
--
Tarek Ziadé
On Tue, Sep 27, 2011 at 3:00 PM, Wichert Akkerman wich...@wiggy.net wrote:
On 09/27/2011 02:51 PM, Tarek Ziadé wrote:
On Tue, Sep 27, 2011 at 2:39 PM, Wichert Akkermanwich...@wiggy.net
wrote:
..
I understand where you're coming from but, ..
I think it's saner to rely on proven technology
logo
raises, slowly
But in any case, I'd rather have a Pythoneer from our community behind
every mirror server, I can trust
/music
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
/moin/BetterPyPI
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
seen the same issue in Mac OS X with namespace packages that are
more than one level deep. 'zope.server' works fine, 'zope.app.server'
(or any other 'zope.app.*') blows up. Works fine with distribute
0.6.16, blows up with 0.6.17.
On Tue, May 31, 2011 at 4:04 AM, Tarek Ziadé ziade.ta
On Wed, Jun 1, 2011 at 12:01 PM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
Op 01-06-11 10:27, Tarek Ziadé schreef:
Aurélien has fixed the issue:
https://bitbucket.org/tarek/distribute/changeset/191f38f47256
Could someone double-check by running the tip, that everything is now
--
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek
On Tue, May 31, 2011 at 12:29 PM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
Op 31-05-11 12:04, Tarek Ziadé schreef:
On Tue, May 31, 2011 at 11:50 AM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
ImportError: cannot import name utils
When I go in with a pdb
-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
I think this regression could be related to this change:
https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
Would you mind trying to revert this change in your environment to see
if the problem goes away ?
Thanks
On Tue, May 31, 2011 at 12:40 PM, Tarek Ziadé ziade.ta...@gmail.com
On Tue, May 31, 2011 at 1:43 PM, Maurits van Rees
m.van.r...@zestsoftware.nl wrote:
Op 31-05-11 12:43, Tarek Ziadé schreef:
I think this regression could be related to this change:
https://bitbucket.org/tarek/distribute/changeset/a3f0d30e94c2
Would you mind trying to revert this change
Hello
I've pushed 0.6.17, which fixes the Python 3.2.1 compat' and a few
bugs. Thanks to the people involved in this release.
If you have any issue with this release, or want to see a particular
problem fixed in the next one, let me know
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
/tarek/distribute/issue/205
If you see anything that you'd like to be fixed in this release,
please point me a bug or a patch today or tomorrow.
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
this week-end for the upcoming python
3 release, I'll see if I can add a patch for this problem
Thanks
Thanks,
Erik
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http
On Wed, May 11, 2011 at 6:44 PM, Jim Fulton j...@zope.com wrote:
On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, May 11, 2011 at 3:21 PM, Jim Fulton j...@zope.com wrote:
...
Not sure to folllow. You want to port Setuptools into py3k... again ?
If so
On Thu, May 12, 2011 at 3:28 PM, Jim Fulton j...@zope.com wrote:
On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, May 11, 2011 at 6:44 PM, Jim Fulton j...@zope.com wrote:
On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
On Wed, May 11
Distribute
once it has added the PEP forward compat layer
(unless Setuptools also adds it, so both will work)
I hope this is clear :)
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
next time ?
Thx and sorry
Tarek
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG
?
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
What are the features that you need ? I'd be interested to know wrt
packaging package we're adding in Python to see if it can be useful there
Cheers
Le 19 mars 2011 07:23, Jim Fulton j...@zope.com a écrit :
2011/3/19 Adam GROSZER agros...@gmail.com:
Hello,
As Jim wants to dump setuptools
, but should be soon.
Let us know how it works out for you.
Thanks for any comments,
Erik
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
On Wed, Mar 16, 2011 at 10:41 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Tarek Ziadé ziade.tarek at gmail.com writes:
I will cut a release during the sprint, unless someone involved in the
project would like to volunteer to do a release.
It's great that a 0.6.15 has been uploaded
://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
duplicated at the top also. Not sure whether
it's big enough :-)
Regards,
Martin
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
- Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
://pypi.python.org/pypi/distribute/0.6.9
and you also say for 2/ if you think your page should have links to
older releases, you are free to make it yourself already
But same remark: it makes browsing more friendly.
And I think a link to packages.python.org/distribute is at the same level
--
Tarek Ziadé | http
2011/3/6 Tarek Ziadé ziade.ta...@gmail.com:
...
and you also say for 2/ if you think your page should have links to
s/ you also / you could have also /
(not clear otherwise)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
IIRC
HTH
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
1 - 100 of 1091 matches
Mail list logo
