<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Arial, sans-serif" size="2">
<div>With regards to messages #104 and #109, I have the following notes.</div>
<div> </div>
<div>> <font face="Courier New, monospace">The Perl pip package didn't show any</font><font face="Courier New, monospace"> </font><font face="Courier New, monospace">liveliness</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">You clarify this in #109, but if by this you mean you checked Google and Debian and then assumed that was enough I agree.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">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.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">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. <a href="http://search.cpan.org/search?query=pip&mode=all"><font face="Arial, sans-serif" size="3" color="#0000FF"><u>http://search.cpan.org/search?query=pip&mode=all</u></font></a><font face="Arial, sans-serif" size="3"> </font></font></div>
<div><font face="Arial, sans-serif" size="3"> </font></div>
<div>> <font face="Courier New, monospace">as not packaged,</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">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).</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">><font face="Courier New, monospace"> and both our commands are superseded by</font> <font face="Courier New, monospace">another old command line</font></font></div>
<div><font face="Courier New, monospace">><font face="Courier New, monospace"> tool called pip for dealing with pipes</font></font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>True</div>
<div> </div>
<div>> <font face="Courier New, monospace">that</font><font face="Courier New, monospace"> </font><font face="Courier New, monospace">project isn't causing any naming problems despite having had a better online<br>
presence than pip</font><font face="Courier New, monospace">.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>> <font face="Courier New, monospace">No one asked or even suggested I</font><font face="Courier New, monospace"> </font><font face="Courier New, monospace">rename pip when I announced the name,</font></div>
<div><font face="Courier New, monospace">><font face="Courier New, monospace"> someone merely noted that a tool with</font> <font face="Courier New, monospace">the same name existed.</font></font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">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.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Courier New, monospace">As for nobody suggesting you rename it...</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><font face="Arial, sans-serif" size="3"><a href="http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/"><font color="#0000FF"><u>http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/</u></font></a> </font></div>
<div><font face="Arial, sans-serif" size="3"> </font></div>
<div><font face="Courier New, monospace">James Bennett kicked off the alternate naming discuss with the humerous suggestion of <font face="Arial, sans-serif" size="3">pippiintpip (”pippiintpip installs Python packages, it is not the Perl Installation Program”).</font></font></div>
<div><font size="3"> </font></div>
<div><font size="3">"Grink" expressed support for the Perl version, and suggested pypi.</font></div>
<div><font size="3"> </font></div>
<div><font size="3">"flowblock" complained it was too much like pypi, and then suggested renaming to the (excellent in my opinion) "pyp".</font></div>
<div><font size="3"> </font></div>
<div><font size="3">And Anatoly Techtonik suggests the alternate name of "pint".</font></div>
<div><font size="3"> </font></div>
<div>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.</div>
<div> </div>
<div>Moving on to #109</div>
<div> </div>
<div>> <font face="Courier New, monospace"> </font><font face="Courier New, monospace">Just </font><font face="Courier New, monospace">to confirm my intuition, I did a little bit of research:</font></div>
<div>></div>
<div>> <font face="Courier New, monospace">* Perl pip 1.16 was release November 2009, pip 0.13 (the previous version)<br>
</font><font face="Courier New, monospace">> </font><font face="Courier New, monospace">was released December 2007. There's no evidence of development in the svn<br>
</font><font face="Courier New, monospace">> </font><font face="Courier New, monospace">repository between those times, why 0.13 jumped to 1.16 I don't know.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div><a href="http://search.cpan.org/~adamk/pip-1.16/"><font color="#0000FF"><u>http://search.cpan.org/~adamk/pip-1.16/</u></font></a></div>
<div> </div>
<div>Here's the main distribution page for pip.</div>
<div> </div>
<div>The current version is 1.16.</div>
<div> </div>
<div>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).</div>
<div> </div>
<div><a href="http://search.cpan.org/src/ADAMK/pip-1.16/Changes"><font color="#0000FF"><u>http://search.cpan.org/src/ADAMK/pip-1.16/Changes</u></font></a></div>
<div> </div>
<div>According to the Changes file, the previous version was 1.15, which was preceded by 0.14.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>> <font face="Courier New, monospace">* Python pip 0.2 was released October 2008 and has had 11 releases since</font><font face="Courier New, monospace"> </font><font face="Courier New, monospace">then.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>> <font face="Courier New, monospace">* Perl's pip has 3 open bugs and zero closed bugs.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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).</div>
<div> </div>
<div>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.</div>
<div> </div>
<div><font face="Courier New, monospace">> <font face="Courier New, monospace">* Python's pip has 37 open bugs (okay, more than I'd like) and 44 closed<br>
bugs.</font></font></div>
<div>> <font face="Courier New, monospace">* Python's pip has 41 forked repositories and 160 followers on bitbucket.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>> <font face="Courier New, monospace">* I've invested significantly in the pip name and idea. I see no evidence<br>
</font><font face="Courier New, monospace">> </font><font face="Courier New, monospace">of any such investment for Perl's pip. Zero.</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>> <font face="Courier New, monospace">* Maybe there is a shadow user base of Perl's pip, but if so</font></div>
<div><font face="Courier New, monospace">><font face="Courier New, monospace"> they've</font> <font face="Courier New, monospace">boycotted the web.</font></font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>Since you mention it, I believe it's also been mentioned in a German Perl magazine as well.</div>
<div> </div>
<div>> <font face="Courier New, monospace">* There have been 82k cumulative downloads of Python pip via PyPI (I can't<br>
</font><font face="Courier New, monospace">> </font><font face="Courier New, monospace">compare to Perl's pip though, as CPAN doesn't track these numbers).</font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div>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.</div>
<div> </div>
<div><font face="Courier New, monospace">> <font face="Courier New, monospace">There have been 126k cumulative downloads of virtualenv which include<br>
</font>> <font face="Courier New, monospace">Python pip (virtualenv has included pip since version 1.3.1)</font></font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>There have been 475k cumulative downloads of the headline Google Code distributed versions of Strawberry Perl</div>
<div>which include Perl pip (Strawberry has included pip since the January 2008 quarterly release).</div>
<div>It's also installed in the Padre standalone Perl distributions for Windows, Mac and Linux.</div>
<div>And it's included in the FOSWiki Windows installer as well, I believe.</div>
<div> </div>
<div><font face="Courier New, monospace">> <font face="Courier New, monospace">So I'll stand firmly by the name: I and a lot of other people have invested<br>
</font>> <font face="Courier New, monospace">in the code, the brand, and the idea of Python's pip, and I see no evidence<br>
</font>> <font face="Courier New, monospace">of any investment in Perl's pip. It's hard to find a name for a project,<br>
</font>> <font face="Courier New, monospace">requiring that there be no overlap with any discarded or lightly maintained<br>
</font>> <font face="Courier New, monospace">project out there is too much to ask.</font></font></div>
<div><font face="Courier New, monospace"> </font></div>
<div>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.</div>
<div> </div>
<div>This problem could easily have been resolved before it happened with a trivial search on the other two P language primary repositories.</div>
<div> </div>
<div>This problem could easily have been resolved on the very first day the original mistake was made clear.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Two different people told you about the collision, and 3 people suggested alternative names (I'll ignore the joke name)</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Adam K</div>
<div> </div>
</font>
<br><br>
<p align="left">
<font color="#000000">
<small>
The information contained in this email and any attached files are strictly <br />
private and confidential. This email should be read by the intended addressee <br />
only. If the recipient of this message is not the intended addressee, please <br />
call Corporate Express Australia Limited on +61 2 9335 0555 or Corporate Express <br />
New Zealand Limited on +64 9 271 7600 and promptly delete this email and any <br />
attachments. The intended recipient of this email may only use, reproduce, <br />
disclose or distribute the information contained in this email and any attached <br />
files with Corporate Express' permission. If you are not the intended addressee, <br />
you are strictly prohibited from using, reproducing, disclosing or distributing <br />
the information contained in this email and any attached files. Corporate <br />
Express advises that this email and any attached files should be scanned to <br />
detect viruses. Corporate Express accepts no liability for loss or damage <br />
(whether caused by negligence or not) resulting from the use of any attached <br />
files.
</small>
</font>
</p>
</body>
</html>