Explicit bootstrapping of pip in Python installations
Published in 2013, this chronicle by @oellegaard details the mechanics of building a profitable, self-funded business without venture backing.
Core Principles for Independent Builders:
Charging customers from day one acts as the ultimate filter for building software that solves genuine, high-urgency problems.
Keeping fixed overhead low and leveraging lean infrastructure allows founders to stay alive until market tailwinds kick in.
Small, repetitive improvements in customer retention and conversion rates yield massive returns over multi-year horizons.
Community Debate Themes:
The community focused on B2B customer acquisition channels, cold email vs SEO distribution, and balancing full-time employment with side-project development.
CATEGORY Bootstrapping & MRR →
HISTORICAL ERA Web 2.0 Genesis (2007–2013)
COMMUNITY SCORE 298 points
TOTAL DISCUSSIONS 77 comments
Hopefully it will also bring about some improvements to pip. It's a pretty great tool but with a couple major caveats. The first is that although it supports many forms of package specification, including VCS repositories, it does not report the package spec according to the way that it was installed, but rather according to the package name and version according to its setup.py. Say you install a package from a git commit that fixed a bug in the PyPI 1.0.0 package whose version is still reported as 1.0.0 in setup.py at the commit. Then you freeze the environment to requirements.txt to distribute. It's still reported as package==1.0.0 instead of the git spec, so the next person to install will pull down the broken version from PyPI instead. The other headache is that installing from a requirements file just installs dependencies in the order they're listed, so oftentimes you need to re-organize the output of `pip freeze` to make sure dependencies are installed in the right order, otherwise you can encounter things like unexpected package versions due to other packages making ambiguous dependency specs for dependencies of your own app.
I kinda of like this... but then again I'm kind of wary.
Isn't the standard library the place where packages go to die?
Isn't the reason pip is actually useful because has a nice health release cycle (http://www.pip-installer.org/en/latest/news.html ↗) and isn't frozen into the standard-library ice age of the past?
Won't this make it even harder to build a compliant version of python that runs on mobile devices where you can't install packages (>_> iOS)?
I get that it's convenient, I'm not 100% convinced its a good idea.
Edit: Reading the PEP in detail its now clear that this is not bundling pip with python (see 'Including pip directly in the standard library'). This is bundling a pip installer as part of the standard library. Much better.
Python packaging has been a nightmare compared to RubyGems (which is not without its own problems, of course). See for example this rant by a major Python developer: http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/ ↗
This sounds like a great step forward to me in making Python packages easy to create, install, and uninstall!
Vaguely related, this wonderful article by Paul Tagliamonte on how pip coexists with distro package managers (in this case APT): http://notes.pault.ag/debian-python/ ↗
Nice reminder that pip is a dev tool and should be used as such. It makes sense to be included in Python.
I like pip, but it's too bad that it can only install from source. It's quite a hassle sometimes to round up dependencies and build them all on windows (not to mention not everyone has a compiler installed on windows).
easy_install can install from binary installers or eggs. I'd like to see that added to pip.