With regards to messages #104 and #109, I have the following notes. > The Perl pip package didn't show any liveliness
You clarify this in #109, but if by this you mean you checked Google and Debian and then assumed that was enough I agree. When I created pip, I did something similar. I checked Debian and found that the binary name was free, checked Google and found only the pipes thing and confirmed it was removed. Given the long history of Perl, Python and PHP dancing around words beginning with P I also checked the main package repositories for all three languages and found nothing. A trivial search for "pip" on search.cpan would have seen the following. http://search.cpan.org/search?query=pip&mode=all > as not packaged, Tprimary distribution method of Perl for software authors is the CPAN (as this covers all operating systems) and the Debian Perl people choose from the 20,000 CPAN packages and run the package automation and do their due diligence as they see fit. There is no expectation for authors to push to have things packaged in Debian. In fact, it's often quite the opposite, as the number of CPAN packages is higher than the total number of Debian packages (or at least, it used to be). > and both our commands are superseded by another old command line > tool called pip for dealing with pipes True > that project isn't causing any naming problems despite having had a better > online presence than pip. What's actually interesting about it is that it's a Perl program, built like a CPAN distribution, but never uploaded to CPAN. But regardless, the last release was in 2003, it hadn't had a release for 5 years before this issue even came up. > No one asked or even suggested I rename pip when I announced the name, > someone merely noted that a tool with the same name existed. I would consider an existing Perl, Python, PHP in any of the big repositories with the same command line a huge red flag, because automated packages methods exist for all of these and it's pretty obvious that there's going to be a naming clash in the downstream. If not immediately, then certainly inevitably. As for nobody suggesting you rename it... http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/ James Bennett kicked off the alternate naming discuss with the humerous suggestion of pippiintpip ("pippiintpip installs Python packages, it is not the Perl Installation Program"). "Grink" expressed support for the Perl version, and suggested pypi. "flowblock" complained it was too much like pypi, and then suggested renaming to the (excellent in my opinion) "pyp". And Anatoly Techtonik suggests the alternate name of "pint". The pyp name in particular seems like a perfect choice, since it fits the py theme and sounds identical so it wouldn't even require a change to spoken conversation. But alternate names are your choice, I only wanted to point out you had 5 people in the renaming discussion. Moving on to #109 > Just to confirm my intuition, I did a little bit of research: > > * Perl pip 1.16 was release November 2009, pip 0.13 (the previous version) > was released December 2007. There's no evidence of development in the svn > repository between those times, why 0.13 jumped to 1.16 I don't know. http://search.cpan.org/~adamk/pip-1.16/ Here's the main distribution page for pip. The current version is 1.16. In the rather prominent "Special Files" section, we can clearly see the Changes file for pip (which has been the file that contains the list of changes for over a decade, even the old pipe-related pip uses it). http://search.cpan.org/src/ADAMK/pip-1.16/Changes According to the Changes file, the previous version was 1.15, which was preceded by 0.14. The 1.15 changes note an upgrade of the packaging, and a switch from a development version (starting in zero) to a production version (starting with a one). This is fairly common thing to do when your distribution has reached maturity and hasn't required any new feature or had any bugs for a while. Personally, I do it after a year without any bugs or fixes being required. As for why it hasn't needed significant improvements, it's because it's a front end application. The application is modular, does a few specific tasks around the packaging and handoff. But most of the work is done by various parts of the pre-existing parts of the toolchain like CPAN.pm, PAR::Dist, Archive::Zip, and so on. Pip also has a good chunk of the backend refactored out for use without all the weight of a command line interface being needed, in the form of things like CPAN::Inject. If python-pip has chosen to go with a more monolithic structure (which is completely understand given the nature of toolchain work, and less mature source repositories) I don't see how that necessarily counts in it's favour. > * Python pip 0.2 was released October 2008 and has had 11 releases since then. Perl pip was released in October 2006 and has had 14 releases since then. CPAN::Inject was created October 2006 outside the pip namespace to provide a generalised approach to CPAN injection, and has had 10 releases since then. Pip also uncovered a number of issues in Perl's primary Archive::Zip, which I took and have done 15 releases of since then, including work funded by a Perl Foundation development grant. Pip also uncovered issues in tarballs and CPAN and CPANPLUS and any number of other places. The total number of releases due to pip or weaknesses uncovered by it is around 40. Fortunately, because all of this core toolchain support exists and doesn't need to be replicated, most bugs in pip aren't actually bugs in pip, they are bugs in a dependency. And so pip itself can reach maturity and convert to doing trickle releases of small pip-specific issues from time to time, while automatically picking up a stream of continuous improvements without any need for a release or work at all. > * Perl's pip has 3 open bugs and zero closed bugs. Perl's pip actually has one bug, although it certainly had a bunch more during it's initial creation. I checked the RT list you mentioned, and killed one that wasn't a bug at all, made a one line change to fix the second (thanks for the reminder). And the third is a feature request, not a bug. And a pretty wish'y feature at that). Of course, if we're competing to have the MOST bugs (if you are treating bug counts as representative of activity) Archive::Zip has 40, cpan has another 50 or so, CPAN::Inject has a number, and so on. > * Python's pip has 37 open bugs (okay, more than I'd like) and 44 closed bugs. > * Python's pip has 41 forked repositories and 160 followers on bitbucket. I don't contest that Python's pip is a larger codebase with a larger scope, and more core, with more scope for bugs to sneak in, and with more people working to improve it. Perl's pip unabashedly provides the ability to install any package of any type onto any operating system. That's all it does, and it does it well. Source packages, binary packages, anything. I don't see how having a program with a more contained scope to precisely what it's name says, and greater use of the luxury of pre-existing libraries to solve most of the hard installation issues, should count against me somehow. Pip doesn't have all this traffic, because it doesn't need it. It works, and it works well, and it had largely reached that point before Python pip even existed. > * I've invested significantly in the pip name and idea. I see no evidence > of any such investment for Perl's pip. Zero. I'm not sure what you mean by this. What kind of information am I supposed to provide here that you haven't found? I can't see any evidence of expensive trade marks, or a company named after it, or even of it's own domain (it's hosted under The Open Planning Project website). And as for the idea of installing packages from a repository, we've all probably invested way too much time in our respective toolchains. > * Maybe there is a shadow user base of Perl's pip, but if so > they've boycotted the web. Pip is used by Padre, the Perl IDE, to install arbitrary packages to the OS. Given the explosion in popularity of Padre, that would certainly count for the popcon numbers. And yes, by and large Perl people don't need to use the public internet as much, as the CPAN cloud provides a huge range of parallel sites. And the very large numbers of sysadmins in Perl's ranks means we have our own IRC network, and the dozen to two dozen sites in the CPAN cloud, and our own repository managers, and so on. Since you mention it, I believe it's also been mentioned in a German Perl magazine as well. > * There have been 82k cumulative downloads of Python pip via PyPI (I can't > compare to Perl's pip though, as CPAN doesn't track these numbers). Correct, there's no real way of measuring CPAN's download numbers. There's 300 mirrors in the network, which makes it pretty much impossible. But it's often mentioned in live support IRC channels, and is used in companies to script multi-step installs where they want to use something other than the latest releases, or want to mix their own non-open-source packages or patched packages into the install sequence. And it's regularly used by CPAN authors to advertise installation of new tarballs that haven't had time to sync to the mirror network yet. > There have been 126k cumulative downloads of virtualenv which include > Python pip (virtualenv has included pip since version 1.3.1) There have been 475k cumulative downloads of the headline Google Code distributed versions of Strawberry Perl which include Perl pip (Strawberry has included pip since the January 2008 quarterly release). It's also installed in the Padre standalone Perl distributions for Windows, Mac and Linux. And it's included in the FOSWiki Windows installer as well, I believe. > So I'll stand firmly by the name: I and a lot of other people have invested > in the code, the brand, and the idea of Python's pip, and I see no evidence > of any investment in Perl's pip. It's hard to find a name for a project, > requiring that there be no overlap with any discarded or lightly maintained > project out there is too much to ask. Clearly preventing collisions with software that nobody uses is an issue, and one I don't feel it's necessary to fix (the download page for the pipe-related pip lists 381 total downloads). But that does not apply in this case. This problem could easily have been resolved before it happened with a trivial search on the other two P language primary repositories. This problem could easily have been resolved on the very first day the original mistake was made clear. This problem could easily have been resolved by mailing the existing pip author's email address (i.e. me) plastered all over the Perl pip documentation and asking what state it was in. Two different people told you about the collision, and 3 people suggested alternative names (I'll ignore the joke name) As someone that clearly does large amounts of toolchain development, if you failed to see the problem would happen, and failed to correct the problem when you were told about it and when it was easy to fix and "just let it go" and didn't even ask me about it, because nobody told you loadly enough to fix it, I fail to see why the onus is on me to resolve a problem of your creation when I was the one that DID do the necessary due diligence to address the issue of naming collision. Adam K The information contained in this email and any attached files are strictly private and confidential. This email should be read by the intended addressee only. If the recipient of this message is not the intended addressee, please call Corporate Express Australia Limited on +61 2 9335 0555 or Corporate Express New Zealand Limited on +64 9 271 7600 and promptly delete this email and any attachments. The intended recipient of this email may only use, reproduce, disclose or distribute the information contained in this email and any attached files with Corporate Express' permission. If you are not the intended addressee, you are strictly prohibited from using, reproducing, disclosing or distributing the information contained in this email and any attached files. Corporate Express advises that this email and any attached files should be scanned to detect viruses. Corporate Express accepts no liability for loss or damage (whether caused by negligence or not) resulting from the use of any attached files.
_______________________________________________ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
