3 ms·

Am I the only person here who thinks the easiest thing to do is to download the python version you need, compile, install in your preferred prefix like any othe

Am I the only person here who thinks the easiest thing to do is to download the python version you need, compile, install in your preferred prefix like any other program and then run it?

zahlman 2y ago
I think that's quite easy, sure. But it's also irrelevant to the discussion. The issue the article is talking about (despite the title) isn't about managing multiple versions of Python. It's with trying to have multiple versions of a third-party library, within a single Python environment.
- tpoacher 2y ago
  Ah you're right, thanks. Admittedly I only skimmed and relied on assumptions of the usual discussion around complaints on the python packaging ecosystem xD Though in principle, my preferred approach here would be similar. Manually install in a particular prefix, add it to the path (manually at runtime or programmatically via the sys module), and then import multiple versions under different namespaces...
  - zahlman 2y ago
    This approach was discussed elsewhere in the thread and you may want to be aware of its limitations (https://news.ycombinator.com/item?id=41706009 https://news.ycombinator.com/item?id=41706009).
    - tpoacher 2y ago
      Thanks! I won't start the same thread here (though thank you for pointing that one out), but when I've come across scenarios similar to those in that thread in my own projects (which, admittedly, while not trivial, were probably not enterprise-scale), the solution generally still involved making sure that one ensured the paths / global variables were suitably modified in the relevant modules before the relevant calls, to ensure you're using the correct namespaces expected by the recipient. Which may be tedious, but to me is not absurd; you're just sticking to the contract expected by the recipient. The bigger issue here (for me) is probably whether those contracts are visible/explicit or not, and how/whether the contract is enforced in the recipient library ... but I would hesitate to call this a multiversion / dependency problem.

Am I the only person here who thinks the easiest thing to do is to download the python version you need, compile, install in your preferred prefix like any other program and then run it?

zahlman 2y ago

I think that's quite easy, sure. But it's also irrelevant to the discussion. The issue the article is talking about (despite the title) isn't about managing multiple versions of Python. It's with trying to have multiple versions of a third-party library, within a single Python environment.

tpoacher 2y ago
Ah you're right, thanks. Admittedly I only skimmed and relied on assumptions of the usual discussion around complaints on the python packaging ecosystem xD Though in principle, my preferred approach here would be similar. Manually install in a particular prefix, add it to the path (manually at runtime or programmatically via the sys module), and then import multiple versions under different namespaces...
- zahlman 2y ago
  This approach was discussed elsewhere in the thread and you may want to be aware of its limitations (https://news.ycombinator.com/item?id=41706009 https://news.ycombinator.com/item?id=41706009).
  - tpoacher 2y ago
    Thanks! I won't start the same thread here (though thank you for pointing that one out), but when I've come across scenarios similar to those in that thread in my own projects (which, admittedly, while not trivial, were probably not enterprise-scale), the solution generally still involved making sure that one ensured the paths / global variables were suitably modified in the relevant modules before the relevant calls, to ensure you're using the correct namespaces expected by the recipient. Which may be tedious, but to me is not absurd; you're just sticking to the contract expected by the recipient. The bigger issue here (for me) is probably whether those contracts are visible/explicit or not, and how/whether the contract is enforced in the recipient library ... but I would hesitate to call this a multiversion / dependency problem.