Curious, what about environment variables? I like the ability to put my environment variables in my activate script. It seems like if you did things the way the author does, you would need all of your env variables to be global, which could be hazardous
You don't really need a virtualenv
91–100 of 148 posts
Re: You don't really need a virtualenv
#92Could someone ELI7 why python is struggling so hard with dependencies and dependency management when in the Java world this is a solved problem and just works with maven, which is working so damn well it last got updated in November 2019, and the biggest fight going is whether you should use gradle as client instead of maven to access the same dependency ecosystem? I had to set up Python projects for some machine lea…
First, so many tutorials give you terrible information. People don't know about "-m", the "py" command, are told to use sudo and not --user.
The current situation is actually not that bad. With my students, the topic is quickly explained and mastered. But it's not a common occurrence.
However, it is true that it's still not as easy as it could be. Some reasons.
- Python is older than java.
- Python is shipped as part of MacOS and Linux, but using the system Python can cause issues, so it's a trap.
- Python deals with a lot of compiled extensions. Scipy embeds C, fortran and assembly. It's a hard problem.
- The Python project has *tremendously* less resources than java.
- Politics. Lots of it.
- Debian et Red Had packagers made a mess by splitting the python setup in many small packages.
- Python 2/3 transition took attention span from the problem during a decade.
- You often install many python versions on the same machine, which makes things harder.
- Python is used by a huge number of non programmers. Much more than java. This shows in the reported difficulties.
- There are way too many ways to install python. So many combinations of failure modes.
- Microsoft screw up with their store not packaging "py" or the core dev by not packaging it on Unix.
- Anaconda brings as many problems as it solves, and is popular because of enterprise limitations.
Re: You don't really need a virtualenv
#93Earlier quoted context omitted.
I have the opinion that this is because "Deployment" is not a solved issue (or clearly defined and enforced) for Python. C has shared libraries and static compilation (bundling of dependencies) Java has .jar files which probably contain all your dependencies, go and Rust statically compile to something that has minimal dependencies and python has... no clue. Some packages you have to install via your package manager…
Python should just do what JavaScript does and install all dependencies to a project-local folder.
That's literally what the article is about.
Re: You don't really need a virtualenv
#94Man i love the ease of this lib. I've been running between docker, poetry, venvs, and pipenv and they all just SUCK.
Is there a best workflow for using this inside a container?
Re: You don't really need a virtualenv
#95My first attempt, and I get "AttributeError: module 'toml.decoder' has no attribute 'TomlPreserveCommentDecoder'"
So careful, far from stable.
I reported it (https://github.com/frostming/pdm/issues/247) because the project is great and I want it to succeed, but I won't put it in prod any time soon. I prefer my package manager to be stable than fancy.
It's also why I don't use poetry and so on in training. There is always some bug that students will encounter later because there are so many config combinations they can encounter, but recent tools have not been as battle tested as we think: the enterprise world is a wild beast.
Re: You don't really need a virtualenv
#96Curious, what about environment variables? I like the ability to put my environment variables in my activate script. It seems like if you did things the way the author does, you would need all of your env variables to be global, which could be hazardous
You could replace that with a tool like direnv. It’ll automatically load your variables for a project when you enter it’s directory.
Re: You don't really need a virtualenv
#97Thanks for giving a look and leaving so many reactions. This project was originally built to experiment on some new PEPs on Python packaging and it turned out working well. 1. What does PEP 582 differ from virtualenv, it is just another "virutualenv" The biggest difference, as you can see, is __pypackages__ doesn't carry an interpreter with it. This way the packages remain available even the base interpreter gets rem…
How does PDM deals with binary python modules like foo.so that in turn depend on other binary libraries like mylib.so? This is what conda manager and conda environments are great for, covering the ground for all major platforms.
Re: You don't really need a virtualenv
#98Earlier quoted context omitted.
Honestly just use poetry.
This comment would be vastly more valuable (to me at least) if you said why. The parent’s workflow mirrors my own and doesn’t feel onerous. Being completely unfamiliar, their site says: > Poetry either uses your configured virtualenvs or creates its own to always be isolated from your system. So it is just a pretty wrapper? I’m missing the value add.
Dependency resolution is the biggest win with Poetry for me - everything everyone else has already said too, but the guarantee that it's only going to install versions of packages that are compatible with each other is fantastic for peace of mind. I can't imagine every using a requirements.txt again.
Re: You don't really need a virtualenv
#99Could someone ELI7 why python is struggling so hard with dependencies and dependency management when in the Java world this is a solved problem and just works with maven, which is working so damn well it last got updated in November 2019, and the biggest fight going is whether you should use gradle as client instead of maven to access the same dependency ecosystem? I had to set up Python projects for some machine lea…
> I had to set up Python projects for some machine learning classes in college and it was a complete mess.
"Machine learning" here is crucial I suppose. Sklearn, keras are big beasts.
Would you install something like django/flask site than I don't think you would had any problems.
Re: You don't really need a virtualenv
#100Earlier quoted context omitted.
JavaScript's package management is significantly better than Pythons: - There's one tool to use, and it comes pre-installed - You don't have to deal with virtualenvs or packages from different projects conflicting. - Native code dependencies "just work".
That one tool must be yarnnpmgypbabelwebpack?
which gets defined in Yet Another YAML Language