Kenneth Reitz is a Python developer who created Requests and Pipenv and writes about tooling, open source burnout, and mental health.
Commenters discuss Pipenv's design choices like project-local environments, and HN links his essays and the controversy around his personal writing and a related apology.
I would recommend Python 3 for sure. I just use the installers from https://www.python.org/ and don't tend to have any problems.
I prefer lightweight tools, so I use Visual Studio Code. It won't hold your hand, but neither will it get in your way.
When working on projects, get in the habit of using virtualenvs. It's a small amount of overhead, but will save you a ton of frustration in the long run. A primer on windows:
From project directory, initialize it:
> python -m venv .env
(I put my virtualenvs in .env out of habit. Virtualenvwrapper, itself a useful addition for managing virtualenvs, puts them in your home directory, which can be fine too.)
Activate it:
> .env\Scripts\activate.bat
Use "pip" to install your dependencies. Also use "pip freeze" to record those dependencies for installations elsewhere. I'm currently following this for dependency management: https://www.kennethreitz.org/essays/a-better-pip-workflow
Interestingly the author states his symptoms started through a combination of lack of sleep and dating a disturbed individual [1].
Such a diagnosis is possibly offensive, ableist and unscientific, however there are many such anecdotal reports of people with (developing or fully developed) mental illness pairing up.
While there is little evidence of such pairing up being a cause (i.e. some sort of "contagiousness", as explored in [2]), there is some evidence that people suffering from mental illness (including personality disorders) can be attracted to one another [3].
[1] http://www.kennethreitz.org/essays/purging-the-unexpected-negative-a-narcissistic-partner
[2] http://www.rawstory.com/2015/12/is-mental-illness-contagious/
[3] http://www.medicaldaily.com/law-attraction-mental-illness-marriage-375268
I use separate requirements-to-freeze.txt and requirements.txt, so that I maintain only list of direct dependencies (no transitive dependencies) and only pin versions when I know the code won't work with the latest version, but pip freeze creates a file like package lock with all the dependencies versioned so I can recreate the exact environment again without needing to store a docker image of it or something like that. See https://www.kennethreitz.org/essays/a-better-pip-workflow
Needing to name the requirements file and needing to activate venv are not pain points I feel.
Wrapping native libraries and not invoking a C compiler at package install time means some trade-offs. https://cffi.readthedocs.io/en/latest/cdef.html
One can argue semantics whether you call it a UI or a CLI, but hey. There's a number of GUI clients out there that depending on your criteria could be considered better. They're usually not as powerful as the CLI client though, and if they are, features like accessing the reflog are hard to find and use. There's also a few alternative CLIs out there, I've just done a quick googling and came across http://www.saintsjd.com/2012/01/a-better-ui-for-git/ and http://www.kennethreitz.org/essays/legit-the-sexy-git-cli.
Personally I prefer the CLI, it's the only tool that I can rely on to do what I tell it to do and to know what's happening. But it takes time and effort to get used to it.
We use different files for "soft" requirements, dev/test requirements, and a freeze.txt containing all production requirements and then we default to installing from freeze.txt but can update from the other files. It's similar to this[1] but generating the freeze.txt in a temporary virtualenv.
I've started using an generated offline cache and PIP_FIND_LINKS to remove the dependency of pypi for known installs in one project as well, will be interesting to see if it turns out to be a good idea or not.
[1]: https://www.kennethreitz.org/essays/a-better-pip-workflow
It's the least shitty of all other designs. It picked the best design decisions from existing package managers. By default it is project local (as opposed to global like what rubygems, pip, and others are), it's recursive and largely reproducible (fully reproducible using lock files). The resolution algorithm is also deterministic and simple, you can implement it in an hour.
Although other languages are catching up they have to do it as add-ons or third party tools -- for example python pipenv https://www.kennethreitz.org/essays/announcing-pipenv