Show HN: Hatch – A modern project, package, and virtual env manager for Python
github.com
github.com
> Creates a new Python project. Think of an "egg" as a new idea.
How does this differ from the egg distribution format [1] introduced by setuptools, which wheel aims to replace? If it's completely different, couldn't a distinct term be used? Python packaging is confusing enough as it is!
But I agree. Creating a new distinct keyword for that command (why not just `hatch new my-app`?) would be far better. I've tried to get into Python packaging, and it's the biggest PITA I've dealt with as a dev.
But it's still a mess only Rube Goldberg could love.
pip
easy_install
virtualenv
mkvirtualenv
pipenv
pyenv
easy_install: Forget it existed, substitute with pip
virtualenv: A virtual environment, providing an isolated Python and libraries
mkvirtualenv: A script to create a virtualenv
pipenv: Combines pip and virtualenv into an integrated solution, comes with a Pipfile not unlike Ruby's Gemfile for example
pyenv: Script that helps to install and manage different Python versions on your system, so you can have the full range of Python 2.x and 3.x installed without them getting in the way of each other. Allows you to set local, default and system Pythons allowing you to switch your Python interpreter depending on which project/directory you're in
pyenv-virtualenv is a wrapper to allow pyenv and virtualenv to work together
Yet there is a monolithic additude towards tooling for languages, so much so that experimentation is actively discouraged. In my experience, there is no better way to level up as a developer than releasing and supporting an actual product that solves what you see as problems. Sure, you can contribute to existing projects, but you're going to learn a lot more if you are the owner. This experience, in and of itself, makes it worth it. I don't understand the existential fear and admonishment since the 'superior' tool will be most widely used. Also, there are many more developers today of all stripes and skill levels, more than enough to support the existing toolset, and others that like to play around and experiment with different projects for fun. This is somewhat how biological evolution works... lots of experiments(mutations), almost all are dead ends, but sometimes, that experiment leads to a wildly successful adaptation.
I only have about 4 years experience, but I've never understood this mindset. I see the value of having a primary toolset for a language, but don't see the value of having onw and only one solution. Can someone please explain to me its value?
You can define a .tools-versions file in the root of your project, which lets you install the correct versions with a simple `asdf install`. We even use this in CI for zero-config language version upgrades.
I started reading the readme, and after getting past general "this is awesome", I got to the doc of the config option...
How about showing an example usage, which does something simple and cool?
If I had to say what is truly novel here, it would be the virtual env management and shell support.
Hatch can replace Conda as a virtual env manager but doesn't really try to compete with it in regards to binary installs.
Hatch does try to detect when a Conda env is in use and will adjust the shell prompt accordingly. https://github.com/ofek/hatch/blob/59cfdd4a929240dd82b2e4e25...
http://docs.pipenv.org/en/latest/
Very different tools, but they cover the same surface area, in spots.
I expect I'll be writing quite a few pull requests.
- comparison with pipenv
- how it handles things like `pip freeze` for, e.g., Heroku
More or less, hatch manages packages based on environments, whereas pipenv does so based on projects.
When pip supports Pipfiles, hatch will as well. At that point, project based package management will be supported too.
Eventually, yes.
Plus, a virtualenv is a much simpler tool, it's essentially just a way to tell the Python interpreter from which directories to load modules, so it's less likely to give you problems.
Also, want to emulate multi-sites on single machine deployment? You need virtualenv.
And by the way, you don't actually need virtualenv :) we run multiple webapps on a machine by just installing dependencies in a directory (pip -t) in the git repo, and then adding the appropriate PYTHONPATH in the service's startup config. As long as you don't need multiple versions of the Python interpreter, this works fine.
...with a very computationally expensive solution, and without improving other aspects like security.
A systemd unit on a "chroot" can do the same and provide isolation.
Change in requirements means rebuilding the container which is a very computationally and IO expensive process. So if you can get away with it virtualenv is better, but putting everything in a container so you can simply ship a container is also useful. It's a compromise.
And by tooling, I mean command line. I am using Cmder with Linux subsystem for Windows, and it STILL isn't half as good as even the terminal built into osx, let alone iterm.
The environment I work with has docker containers for
Web App Server
Background Task Worker Server
Database
Redis Node
Cassandra Node
Most of the time, I only need to work on functionality that depends on DB and WEB nodes, but if I ever need to debug some issue with the worker tasks, it's much easier to have a whole working system available.
As of writing this comment, this submission has 4 points in 3 hours, and is on the top half of the front page. (Not saying the project doesn't shouldn't be - looks pretty awesome tbh).
Does the reputation of the people upvoting it matter? (still surprising it'd rise given only 4 points in 3 hours). Does the reputation of the person submitting it matter?
And don't use random topics to ask questions like these, that's what Ask HN can be used for: https://news.ycombinator.com/ask