4 ms·

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I

Sometimes I feel people are using Python very differently than me. I just use pip freeze and virtualenv (these are Python basics, not some exotic tools) and I feel it works great. Granted, you don't get a nice executable, but it's still miles ahead of C++ (people literally put their code into header files so you don't have to link to a library), and even modern languages like rust (stuff is always broken, or I have some incompatible version, even when it builds it doesn't work) By the way if you're a Python user, Nim is worth checking out. It's compiled, fast and very low fuss kind of language that looks a lot like Python.

pdimitar 4y ago
> and even modern languages like rust (stuff is always broken, or I have some incompatible version, even when it builds it doesn't work) Been working on and off with Rust for the last 3 years, never happened to me once -- with the exception of the Tokio async runtime that has breaking changes between versions. Everything else always worked on the first try (checked with tests, too). Comparing Python with C++ doesn't make do argument any favours, and neither does stretching a single Rust accident to mean the ecosystem is bad.
- mcronce 4y ago
  This is consistent with my experience. Semantic versioning is very very widely used in the Rust ecosystem, so you're not looking at breaking changes unless you select a different major version (or different minor version, for 0.x crates) - which you have to do manually, cargo will only automatically update dependencies to versions which semver specifies should be compatible. For crates that don't follow semver (which I'm fairly certain I've encountered zero times) you can pin a specific exact version.
tempest_ 4y ago
Comparing anything to C++ is a very low bar. I have rarely encountered issues in rust. Most rust crates stick to semver so you know when there will be a breaking change. My rust experience with Cargo can only be described as problem free(though I only develop for x86 linux). As for pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies (which in various parts of the ecosystem is a lot) as well as different python versions (if you are supporting any kind of legacy software). This is also assuming other people working on the same project have the same python yadda yadda the list goes on, its not great.
- fiddlerwoaroof 4y ago
  The issue I’ve encountered in rust is looking at a library and seeing that it requires a nightly build of the compiler.
- geysersam 4y ago
  > pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies Yes 100 times. That can be incredibly frustrating. During the last year I've used a large (and rapidly evolving) C++ project (with many foss C/C++ dependencies) with Python bindings. We've collectively wasted sooo many hours on dependency issues in the team. Long compilation times contribute considerably to slow down the feedback loop when debugging the issues.
fiddlerwoaroof 4y ago
When I was a Python dev, I never saw that happen in ten years or so of work. Pip freeze and virtualenv just worked for me. I will say, though, that this only accounts for times where you’re not upgrading dependencies. Where I’ve always run into issues in Python was when I decided to upgrade a dependency and eventually trigger some impossible mess.
- mypalmike 4y ago
  Upgrading dependencies is fraught in all languages.
  - oars 4y ago
    Haven't had any issues in Go so far.
    - mypalmike 4y ago
      As soon as you take 2 dependencies in any language, there's a chance you will not be able to upgrade both of them to latest versions because somewhere in the two dependency subgraphs there is a conflict. There's no magic to avoid this, though tooling can help find potentially working versions (at least by declaration). It's often the case that you don't encounter conflicts in Python or other languages, but I don't imagine that Go is immune.
      - jhardy54 4y ago
        Are you familiar with npm? I haven’t used it deeply in years, but the last time I checked it still supported conflicting dependencies. If A and B both depend on different versions of C, then both versions of C are installed and A/B see the version they want.
        mypalmike 4y ago
        I've used npm but an not familiar with these kinds of details of it. There would seem to be some potential putfalls, such as two libraries accessing a single system resource (a config file, a system socket, etc.). I will take a look into this though. Thanks.
smeagull 4y ago
If I did that I'd have no harddrive space left due to how large python dependencies are.
- Spivak 4y ago
  Wat? What dependencies? I have right now 100 separate Python projects which each have their own venv, their own isolated dependencies, and their own isolated copy of Python itself and my code dir doesn’t even crack top 10 hard drive space.
  - deleted 4y ago
    [deleted]
  - Game_Ender 4y ago
    Machine learning packages like Tensorflow can result in GB size package directories.
    - stavros 4y ago
      Yes, the biggest available library is big, that's hardly an argument though.
      - smeagull 4y ago
        A really common library that gets used in every project for common use-cases is big. It's a very good argument.
        stavros 4y ago
        No, saying "one common library is big" isn't a good way to show that "Python dependencies are big", which is what the initial claim was. Most libraries are tiny, and there's a very big one because it does many things. If Tensorflow were in JS it wouldn't be any smaller.
rewgs 4y ago
Yup. PyEnv for installing various versions. /path/to/pyenv/version/bin/python -m venv venv. Activate the venv (I made "av" and "dv" aliases in my .zshrc). Done, proceed as usual.

pdimitar 4y ago

> and even modern languages like rust (stuff is always broken, or I have some incompatible version, even when it builds it doesn't work) Been working on and off with Rust for the last 3 years, never happened to me once -- with the exception of the Tokio async runtime that has breaking changes between versions. Everything else always worked on the first try (checked with tests, too). Comparing Python with C++ doesn't make do argument any favours, and neither does stretching a single Rust accident to mean the ecosystem is bad.

mcronce 4y ago
This is consistent with my experience. Semantic versioning is very very widely used in the Rust ecosystem, so you're not looking at breaking changes unless you select a different major version (or different minor version, for 0.x crates) - which you have to do manually, cargo will only automatically update dependencies to versions which semver specifies should be compatible. For crates that don't follow semver (which I'm fairly certain I've encountered zero times) you can pin a specific exact version.

tempest_ 4y ago

Comparing anything to C++ is a very low bar. I have rarely encountered issues in rust. Most rust crates stick to semver so you know when there will be a breaking change. My rust experience with Cargo can only be described as problem free(though I only develop for x86 linux). As for pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies (which in various parts of the ecosystem is a lot) as well as different python versions (if you are supporting any kind of legacy software). This is also assuming other people working on the same project have the same python yadda yadda the list goes on, its not great.

fiddlerwoaroof 4y ago
The issue I’ve encountered in rust is looking at a library and seeing that it requires a nightly build of the compiler.
geysersam 4y ago
> pip freeze and virtualenv things start to fall apart especially quickly when you require various C/C++ dependencies Yes 100 times. That can be incredibly frustrating. During the last year I've used a large (and rapidly evolving) C++ project (with many foss C/C++ dependencies) with Python bindings. We've collectively wasted sooo many hours on dependency issues in the team. Long compilation times contribute considerably to slow down the feedback loop when debugging the issues.

fiddlerwoaroof 4y ago

When I was a Python dev, I never saw that happen in ten years or so of work. Pip freeze and virtualenv just worked for me. I will say, though, that this only accounts for times where you’re not upgrading dependencies. Where I’ve always run into issues in Python was when I decided to upgrade a dependency and eventually trigger some impossible mess.

mypalmike 4y ago
Upgrading dependencies is fraught in all languages.
- oars 4y ago
  Haven't had any issues in Go so far.
  - mypalmike 4y ago
    As soon as you take 2 dependencies in any language, there's a chance you will not be able to upgrade both of them to latest versions because somewhere in the two dependency subgraphs there is a conflict. There's no magic to avoid this, though tooling can help find potentially working versions (at least by declaration). It's often the case that you don't encounter conflicts in Python or other languages, but I don't imagine that Go is immune.
    - jhardy54 4y ago
      Are you familiar with npm? I haven’t used it deeply in years, but the last time I checked it still supported conflicting dependencies. If A and B both depend on different versions of C, then both versions of C are installed and A/B see the version they want.
      - mypalmike 4y ago
        I've used npm but an not familiar with these kinds of details of it. There would seem to be some potential putfalls, such as two libraries accessing a single system resource (a config file, a system socket, etc.). I will take a look into this though. Thanks.

smeagull 4y ago

If I did that I'd have no harddrive space left due to how large python dependencies are.

Spivak 4y ago
Wat? What dependencies? I have right now 100 separate Python projects which each have their own venv, their own isolated dependencies, and their own isolated copy of Python itself and my code dir doesn’t even crack top 10 hard drive space.
- deleted 4y ago
  [deleted]
- Game_Ender 4y ago
  Machine learning packages like Tensorflow can result in GB size package directories.
  - stavros 4y ago
    Yes, the biggest available library is big, that's hardly an argument though.
    - smeagull 4y ago
      A really common library that gets used in every project for common use-cases is big. It's a very good argument.
      - stavros 4y ago
        No, saying "one common library is big" isn't a good way to show that "Python dependencies are big", which is what the initial claim was. Most libraries are tiny, and there's a very big one because it does many things. If Tensorflow were in JS it wouldn't be any smaller.

rewgs 4y ago

Yup. PyEnv for installing various versions. /path/to/pyenv/version/bin/python -m venv venv. Activate the venv (I made "av" and "dv" aliases in my .zshrc). Done, proceed as usual.