On Fri, Dec 25, 2009 at 3:27 PM, Lennart Regebro wrote:
> This is true, but the idea to upload them by robots is preferable in
> my opinion. Again it's a difference between trying to force other
> people to behave to your expectations vs trying to make it easier for
> others to behave to your exp
On Fri, Dec 25, 2009 at 05:39, Sridhar Ratnakumar
wrote:
> Is it because of this benefit to package authors that we are withholding the
> implementation of a simple archive that would: 1) simplify the tools to no
> rely on adhoc web scrapping
There are better ways to do that.
> 2) reduce the dow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> On Thu, Dec 24, 2009 at 11:20 AM, kiorky wrote:
> [..]
>>> That said, some people have expressed the desire to be able to
>>> interact with PyPI through SSH so they could drop the basic
>>> authentication and use their keys when r
On 12/24/2009 3:00 AM, "Martin v. Löwis" wrote:
Some reasons to have PyPI host packages have already been mentioned in
> this thread: it makes mirroring easier, and it makes it easier for
> individuals to build new services (web sites primarily) that present new
> interfaces to the Python pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
kiorky wrote:
>
> Lennart Regebro a écrit :
>> On Thu, Dec 24, 2009 at 12:28, kiorky wrote:
>>> Why forcing them ?
>>> How about a cronjob or something like that which find packages without
>>> distribution and get from there all distributions possib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> Ben Finney wrote:
>>> That isn't a good argument. By the same logic, PyPI should not
>>> reject *any* upload, to avoid “forcing” uploaders to do extra work.
>> PyPI's rejection of certain uploads is
On 12/23/2009 10:42 PM, Lennart Regebro wrote:
On Wed, Dec 23, 2009 at 23:28, Sridhar Ratnakumar
wrote:
I suggested PyPI to disallow mere project listings (without sources) and
require sources to be stored in the server. One way to achieve this is
requiring package authors to use the `sdist u
On 12/24/2009 12:33 AM, "Martin v. Löwis" wrote:
1/ Missing packages (eg: Twisted is not there); which is why
easy_install/pip had to resolve to scrapping project webpages for
guessing download links. In CPAN, almost all module authors upload their
sources via PAUSE.
How do you propose to chang
On Dec 24, 2009, at 5:50 PM, Lennart Regebro wrote:
> easy_install is a command, basically a wrapper around setuptools
> install functionality. I doubt many scripts would use it in any more
> complex way than calling it, in which case moving to pip is a matter
> of replacing the command.
Yes, I'm
On Wed, Dec 23, 2009 at 10:32, smuel...@cpan.org wrote:
>> I have to say that I vastly prefer not to have any authorization and
>> allow anyone to release anything in any namespace. But then I am
>> getting fanatically anarchical in these issues. You can not organize
>> freedom.
>
> But you have t
On Thu, Dec 24, 2009 at 22:45, Ben Finney wrote:
> Am I wrong, then, in thinking that PyPI will reject an upload with
> malformed metadata?
Well, define "malformed". If the data format is impossible to
interpret, it obviously have to fail. That's not a reject in any big
sense. There are also requ
On Thu, Dec 24, 2009 at 22:20, kiorky wrote:
>> But uploading to PyPI is for 99.999% of packages so easy that if it's
>> not done there may be a reason why they don't want to.
>
> Unless they don't know how to do.
It's well documented and very easy.
> What i would like to see is just to have mos
On Thu, Dec 24, 2009 at 17:48, sstein...@gmail.com wrote:
> I guess what I mean is that I'd like to make sure that while moving to pip,
> that easy_install, as a command name, not as an implementation, gets brought
> along in the same way that Distribute has brought along setuptools
> compatibi
"Martin v. Löwis" writes:
> Ben Finney wrote:
> > That isn't a good argument. By the same logic, PyPI should not
> > reject *any* upload, to avoid “forcing” uploaders to do extra work.
>
> PyPI's rejection of certain uploads is primarily to prevent spam from
> being uploaded.
Am I wrong, then, i
Lennart Regebro a écrit :
> On Thu, Dec 24, 2009 at 12:28, kiorky wrote:
>> Why forcing them ?
>> How about a cronjob or something like that which find packages without
>> distribution and get from there all distributions possible on their relative
>> homepages and mirror them on Pypi ?
>
> Som
On Dec 24, 2009, at 10:16 AM, Lennart Regebro wrote:
> On Thu, Dec 24, 2009 at 15:46, sstein...@gmail.com
> wrote:
>> I don't think it's strange to be concerned that one of the SDPTJLCOB
>> options, and the one that you used as your example, is going to go away.
>
> Why? Pip does the same thi
Hi,
I have a setup() that uses a version control change number to set the
version of the package. Part of the package includes some
console_script directives. When the scripts are generated the
__requires__ and load_entry_point will be set to the exact version of
the package. I would like to h
Hi Lennart,
thanks for the reply.
Lennart Regebro gmail.com> writes:
> On Tue, Dec 22, 2009 at 10:14, Steffen Mueller cpan.org> wrote:
> > Let me add two nits here:
> > It's Perl, not PERL. The name of the language is *not* an acronym. Some
> > people
> > are really picky about that.
>
> In a
On Thu, Dec 24, 2009 at 15:46, sstein...@gmail.com wrote:
> I don't think it's strange to be concerned that one of the SDPTJLCOB options,
> and the one that you used as your example, is going to go away.
Why? Pip does the same thing. They are commands. And it's not likely
to go away anytime soon
On Dec 24, 2009, at 9:06 AM, Lennart Regebro wrote:
>> I'm really concerned that what you just seemed to suggest was that the
>> much-maligned-and-soon-to-be-deprecated `easy_install` is the
>> `super-duper-python-thing-just-like-cpan-only-better` of today?
>
> That's a strange concern.
I don
On Thu, Dec 24, 2009 at 13:17, Ben Finney wrote:
>> Forcing people to do what you think they should do will not make them
>> make more or better work. It will just make them do *less* work.
>
> That isn't a good argument.
It's a *fantastic* argument.
> By the same logic, PyPI should not reject
>
On Thu, Dec 24, 2009 at 14:44, sstein...@gmail.com wrote:
> Ok, so easy_install works for Twisted. Yay.
So, your requirement is fulfilled.
> I think that's exactly *not*:
>
> # super-duper-python-thing-just-like-cpan-only-better -i Twisted
No, it's
> # super-duper-python-thing-just-like-cpan-
On Thu, Dec 24, 2009 at 12:28, kiorky wrote:
> Why forcing them ?
> How about a cronjob or something like that which find packages without
> distribution and get from there all distributions possible on their relative
> homepages and mirror them on Pypi ?
Somebody (including a bot) uploading a pa
On Thu, Dec 24, 2009 at 2:47 PM, Lennart Regebro wrote:
> On Thu, Dec 24, 2009 at 11:46, David Robins wrote:
>> Some reasons to have PyPI host packages have already been mentioned in
>> this thread: it makes mirroring easier
>
> Uhm, mirroring PyPI, no. Because those packages aren't there. Settin
On Thu, Dec 24, 2009 at 11:46, David Robins wrote:
> Some reasons to have PyPI host packages have already been mentioned in
> this thread: it makes mirroring easier
Uhm, mirroring PyPI, no. Because those packages aren't there. Setting
up your own package server, yes. It's not exactly the same thi
On Dec 24, 2009, at 2:02 AM, Lennart Regebro wrote:
> On Thu, Dec 24, 2009 at 06:06, sstein...@gmail.com
> wrote:
>> Right now, installing e.g. Twisted, requires finding the website, figuring
>> out which exact file to download, then figuring out exactly how to get it
>> installed.
>
> Nope.
Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> The benefits are not to the package users, clearly.
>
> That should immediately make us suspicious, then.
>
> If PyPI is for anything, surely it is for the package recipients *more
> than* for package developers.
I thought so when adding votin
"Martin v. Löwis" writes:
> The benefits are not to the package users, clearly.
That should immediately make us suspicious, then.
If PyPI is for anything, surely it is for the package recipients *more
than* for package developers.
> Instead, they are to the package authors, which don't have to
Lennart Regebro a écrit :
> On Thu, Dec 24, 2009 at 10:25, Ben Finney wrote:
>> "Martin v. Löwis" writes:
> Because otherwise you can't register packages in PyPI without
> uploading them, and that means that those who do not want to upload
> them also will not register them.
> Forcing people
Martin v. Löwis a écrit :
>> Although SSH is quite a heavy development on PyPI side, it means we
>> would have to implement
>> an SSH server. (like Zope did I think for their development server,
>> using Paramiko IIRC)
>
> Not necessarily: it might be possible to use sshd.
Thas was my underlyi
On Thu, Dec 24, 2009 at 12:00 PM, "Martin v. Löwis" wrote:
[..]
>
> There are a number of other mirroring tools, such as EggBasket and
> collective.eggproxy. For mirroring the whole index, pypimirror is
> probably the best starting point.
collective.eggproxy is particular though: it's a proxy-cac
> Some reasons to have PyPI host packages have already been mentioned in
> this thread: it makes mirroring easier, and it makes it easier for
> individuals to build new services (web sites primarily) that present new
> interfaces to the Python package collection. Mirroring for its own sake
> is so
2009/12/24 "Martin v. Löwis" :
>>> python setup.py pickup_files upload
>>>
>>> to upload the pre-built files; thereby you can upload files as source
>>> that had not been generated by sdist.
>>>
>>
>> That's why I've proposed to add a --dist-file option to the upload command,
>
> The tricky thing m
> Although SSH is quite a heavy development on PyPI side, it means we
> would have to implement
> an SSH server. (like Zope did I think for their development server,
> using Paramiko IIRC)
Not necessarily: it might be possible to use sshd.
Regards,
Martin
On Thu, Dec 24, 2009 at 02:59:28AM -, exar...@twistedmatrix.com wrote:
> There have been a few responses to Glyph's mention that "setup.py
> upload" doesn't work for Twisted. I'm much more curious to hear replies
> to his other point - "nobody cares anyway".
>
> What's with the interest in
>> python setup.py pickup_files upload
>>
>> to upload the pre-built files; thereby you can upload files as source
>> that had not been generated by sdist.
>>
>
> That's why I've proposed to add a --dist-file option to the upload command,
The tricky thing may be to find out what kind of file that
>>> And I will not care much about the micro version in that case, since
>>> Python will not change its syntax/API in a micro release.
>> I think that's a mistake. Specifying "2.6" is equivalent to specifying
>> "==2.6". With your proposed meaning of "==", either == is not
>> transitive, or all ver
On Thu, Dec 24, 2009 at 10:25, Ben Finney wrote:
> "Martin v. Löwis" writes:
>
>> I think it should be the choice of the package authors whether they
>> upload their software to the central repository, or to their own home
>> page.
>
> Why do you think that should continue?
Because otherwise you
On Thu, Dec 24, 2009 at 11:20 AM, kiorky wrote:
[..]
>> That said, some people have expressed the desire to be able to
>> interact with PyPI through SSH so they could drop the basic
>> authentication and use their keys when registering/uploading.
>> But that was not related to the size of files.
>
>> I think it should be the choice of the package authors whether they
>> upload their software to the central repository, or to their own home
>> page.
>
> Why do you think that should continue? Some of the costs of that
> inconsistency have already been described in this thread. What are the
> b
Tarek Ziadé a écrit :
> On Thu, Dec 24, 2009 at 11:06 AM, kiorky wrote:
>>
>> Martin v. Löwis a écrit :
> I don't think it worth the pain, with the speed of nowadays
> connections. But I could add a curl upload progress bar in the upload
> command. If you think this is useful let me know.
No. p
On Thu, Dec 24, 2009 at 11:06 AM, kiorky wrote:
>
>
> Martin v. Löwis a écrit :
>>> The tiny 10MB upload is a blocker i think also.
>>> For example, for 'minitage.paste.extras', it's not hosted on pypi because
>>> of that.
>>
>> The limit is 20MB now. If you need a larger limit let me know.
>
> C
Ben Finney a écrit :
> "Martin v. Löwis" writes:
>
>> I think it should be the choice of the package authors whether they
>> upload their software to the central repository, or to their own home
>> page.
>
> Why do you think that should continue? Some of the costs of that
> inconsistency have
2009/12/24 :
[..]
>
> Release packages for Twisted are constructed using some extra file- finding
> logic that sdist doesn't provide. Additionally, for years distutils was
> seen as a blind alley, so we didn't bother to try to create a
> distutils-friendly substitute. Partially because it seems
Martin v. Löwis a écrit :
>> The tiny 10MB upload is a blocker i think also.
>> For example, for 'minitage.paste.extras', it's not hosted on pypi because of
>> that.
>
> The limit is 20MB now. If you need a larger limit let me know.
Cool!
I tested with success the upload.
Size of the dist is 1
On Thu, Dec 24, 2009 at 10:02 AM, "Martin v. Löwis" wrote:
>> A separate issue with "setup.py upload", though, is that it really wants
>> one of two undesirable things:
>>
>> * the upload is done at the same time as the release package is generated
>> * the release package is generated twice
>>
Martin v. Löwis a écrit :
>> The tiny 10MB upload is a blocker i think also.
>> For example, for 'minitage.paste.extras', it's not hosted on pypi because of
>> that.
>
> The limit is 20MB now. If you need a larger limit let me know.
>
> Unfortunately, I cannot find out what the size of minitag
Finally somebody had few doubts about CPAN...please have a look ti a
"just-posted" article on slashdot.
That mess is CPAN was my original reason to discard perl in first (and
switching to python): no two installed perl are ever the same. No way to
reliably reproduce the same environment and no
2009/12/24 "Martin v. Löwis" :
>> Some applications doesn't care about the micro version, but will care about
>> the minor version because those can introduce API and syntax changes.
>>
>> e.g. If at some point I have a Python 2.6 program that uses the "with"
>> keyword, and I don't want to introdu
"Martin v. Löwis" writes:
> I think it should be the choice of the package authors whether they
> upload their software to the central repository, or to their own home
> page.
Why do you think that should continue? Some of the costs of that
inconsistency have already been described in this threa
> A separate issue with "setup.py upload", though, is that it really wants
> one of two undesirable things:
>
> * the upload is done at the same time as the release package is generated
> * the release package is generated twice
>
> The former requires that proper credentials are available to w
> What's with the interest in having packages hosted on PyPI?
"Because it would then be more like CPAN". Some people claim that one
key of CPAN's success is that it has all files stored in the archive,
and that it then allows mirroring with rsync and ftp.
They claim that without that, PyPI can't
> The tiny 10MB upload is a blocker i think also.
> For example, for 'minitage.paste.extras', it's not hosted on pypi because of
> that.
The limit is 20MB now. If you need a larger limit let me know.
Unfortunately, I cannot find out what the size of minitage.paste.extras
is, as their download UR
> 3/ Indices such as http://www.cpan.org/modules/01modules.mtime.html (or
> TXT files) to get a) recently released packages, b) list of release
> versions for a particular package, and so on (which would obviate the
> XmlRpc interface)
That is available as
http://pypi.python.org/pypi?%3Aaction=rs
> 1/ Missing packages (eg: Twisted is not there); which is why
> easy_install/pip had to resolve to scrapping project webpages for
> guessing download links. In CPAN, almost all module authors upload their
> sources via PAUSE.
How do you propose to change that? I think it should be the choice
of t
> Some applications doesn't care about the micro version, but will care about
> the minor version because those can introduce API and syntax changes.
>
> e.g. If at some point I have a Python 2.6 program that uses the "with"
> keyword, and I don't want to introduce a __future__ import in my code,
56 matches
Mail list logo
