Despite disliking Clojure now, I find its (rather: Leiningen's) approach to dependency management the best possible approach: clojure.jar (language core + standard library) is a regular dependency like any other dependency. (Of course this only works because the "real" core is the JVM.)
Pipenv: promises a lot, delivers very little
171–180 of 229 posts
Re: Pipenv: promises a lot, delivers very little
#172I recommend pip-tools along with pyenv and pyenv-virtualenv.
https://github.com/jazzband/pip-tools
Re: Pipenv: promises a lot, delivers very little
#173“Not as good as pip, but it’s more reasonable than Pipenv. Also, the codebase and its layout are rather convoluted. Poetry produces packages instead of just managing dependencies, so it’s generally more useful than Pipenv.”
Can anybody confirm which codebase is being described as convoluted here?
Re: Pipenv: promises a lot, delivers very little
#174I've long freed myself from the exhausting pipenv/virtualenv/pienv/conda rat-race by using docker. The only downside is some annoying IDEs refuse to acknowledge the existence of interpreter in a container.
How?
Re: Pipenv: promises a lot, delivers very little
#175It's unfortunate that more people don't know about pip-tools (it isn't even mentioned in the OP). It + virtualenv hits a sweet spot for speed, usability and utility for me.
Re: Pipenv: promises a lot, delivers very little
#176I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…
As you have experience with pyenv, pipenv and poetry, you might be able to answer: Why not conda? I've been using conda since ~4 years now, and every single complaint lodged against any of the other package managers was never an issue with conda in the first place. And yet, it seems like there's a SEP field around it and people just ignore its existence? In this thread, for the first time, I've seen someone mention t…
Because publishing a package on PyPI is trivial compared to publishing on the Anaconda cloud. For the latter, you need to build your package for every platform and Python version you want to support. So sou need to setup some CI. This is just such an overkill for a pure-Python package. It makes a lot of sense for a project with a nontrivial C extension though, and I do build a conda package for one such project of mine. For everything else, I publish just on PyPI.
Re: Pipenv: promises a lot, delivers very little
#177Earlier quoted context omitted.
Oh, they don't do dot releases anymore, its "CalVer" [1] - aka. Calendar Versioning, aka. release when we feel like it. And why did they do this: > We just switched the project over to calver, with the explicit purpose of preventing [Kenneht Reitz] from making more than one release a day [1] https://calver.org/ [2] http://journal.kennethreitz.org/entry/r-python (Ctrl-F 'calver')
Reitz has self-confessed manic episodes due to bipolar disorder: https://www.kennethreitz.org/essays/mentalhealtherror-an-exc... https://journal.kennethreitz.org/entry/on-mania
I will be down-voted to hell, but sometimes I feel that KR hides behind the illness to avoid responsibility. KR told that he's just "good at marketing" and has "cult of personality" [0] and I do not see an edit that it was "KR the maniac" speaking and not the "KR the normal guy".
Personally, today I'd better use `venv + pip` instead, of `pipenv`, but `pipenv` somehow was the "official" tool for package management for months, until people started discussing it [1]. I would like to have better packaging tools in python, but `pipenv` approach seemed really strange, now I know why.
If you had manic episode and did some mistakes - go and try reverse them. Revert/change the commits. Apologise for the comments you've made. But no, let's get into the position of a victim, when someone criticises you. I believe that KR may have psychological problems and/or illnesses, but his "normal self" seems to be rather egomaniac too and takes bolder claims that he's comfortable to handle. If it would be otherwise - there would be no drama, there would be no fake "official" tools. KR could just enjoy his fame from `requests` and save his time while writing responses on his blog.
[0] http://journal.kennethreitz.org/entry/r-python
[1] https://www.reddit.com/r/Python/comments/8jd6aq/why_is_pipen...
Re: Pipenv: promises a lot, delivers very little
#178What's the recommended Python solution for deploying Python scripts/applications off-line? I am deploying several scripts on machines with no access to the internet, so I can't exactly pip install -r requirements.txt. My current solution is to cache all pip packages in a packages directory and then export PYTHONUSERBASE=$PWD/packages, but it feels like a hack. Virtualenvs are no solution because they aren't portable (hardcoded paths).
Re: Pipenv: promises a lot, delivers very little
#179Pipenv is a really interesting development for Python, and I'm glad that someone was working to improve dependency locking for Python. However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth a…
I'm very glad we have the wheel and ensurepip now. Yet, I think PyPA has not been taking the best decisions regarding Python packaging. Your Kenneth story is not the only "weird event" in their history. E.G: Did you know that we don't need "pyproject.toml" at all ? That there is already a production ready plain text standard to replace setup.py ? Did you know that this standard has been perfectly working for TWO YEAR…
Because I hate the "this ship has sailed" argument about pyproject.toml, here are some github usage stats:
- setup.py: 1,259,007 results (https://github.com/search?q=filename%3Asetup.py)
- setup.cfg: 165,716 results (https://github.com/search?q=filename%3Asetup.cfg)
- pyproject.toml: 2,137 results (https://github.com/search?q=filename%3Apyproject.toml)
Also, remember that setup.cfg is completly compatible with setup.py, the migration is painless. All the legacy tools work. Not the case with pyproject.toml.
Re: Pipenv: promises a lot, delivers very little
#180Earlier quoted context omitted.
I don't understand why this comment isn't higher! Honestly, using `conda` eliminates the pain of python dependency & environment management entirely. Clone a repo, do `conda env create` (from the project's `environment.yml`), then `source activate $ENV_NAME`. Straightforward. Easy. But most importantly, reliable!
It's great but can be a pain if you develop on a mac and try to replicate your env on linux because the env files are not portable. The CLI can be confusing at times too, I always have to google how to create a new env or export it.
The exact use case I use conda for at work is developing on Mac and automatically export the same env to various linux platforms.
Why do you suggest conda doesn’twork for that? It’s one of the things conda specifically does. When recreating the same env on a different platform, it will resolve the dependencies for that platform, so there are no cross-platform issues of the underlying env unless the library being installed simply doesn’t support that platform, in which case _no_ environment manager could possibly solve that specific problem.