3 ms·

There is no real direction in the article. I did not see any takeaway, or some kind of proposition or nice trick? It can pretty much be summed up as "I don't k

There is no real direction in the article. I did not see any takeaway, or some kind of proposition or nice trick? It can pretty much be summed up as "I don't know much of Python and admittedly don't want to spend time on it, so I did a bunch of hacks to download my dependencies and it worked". > Nor do we want to learn about how to build and maintain Python virtual environments I think the author would have better spent his time learning the basic usage of virtualenv/venv than writing this blog post.

jefftk 6y ago
> the author would have better spent his time learning the basic usage of virtualenv/venv than writing this blog post Chris has a very low threshold for writing blog posts: if he does something he writes it up. He also has it set up in a way that's very low overhead for him. I like that he writes these sorts of snapshot blog posts; they're a much better view into what people are actually doing than "I'm going to introduce this shiny new thing" posts.
IshKebab 6y ago
> I think the author would have better spent his time learning the basic usage of virtualenv/venv than writing this blog post. I don't. Virtualenv is a hack to workaround the mess of Python paths that they won't actually fix. I'd put it in a similar bucket as Docker (hacking around the mess of binary software distribution on Linux). I don't want to spend my time learning workarounds.
- gojomo 6y ago
  But, it's a "hack workaround" that a professional consensus has converged upon. Pythonistas have developed supporting tools & help-texts, & many assume the use of silo'd virtual environments as 'basic hygiene' for serious work. The approach is also highly analogous to other "alternate virtual root" solutions across OSes/containers/user-customization schemes. So instead of that, you'd rather... make you own custom hack workarounds? That will be idiosyncratic to your installations/projects? That will hit unique errors/tradeoffs the standard convention has already worked around? That will be harder for others to understand? OK, to each their own!

jefftk 6y ago

> the author would have better spent his time learning the basic usage of virtualenv/venv than writing this blog post Chris has a very low threshold for writing blog posts: if he does something he writes it up. He also has it set up in a way that's very low overhead for him. I like that he writes these sorts of snapshot blog posts; they're a much better view into what people are actually doing than "I'm going to introduce this shiny new thing" posts.

IshKebab 6y ago

> I think the author would have better spent his time learning the basic usage of virtualenv/venv than writing this blog post. I don't. Virtualenv is a hack to workaround the mess of Python paths that they won't actually fix. I'd put it in a similar bucket as Docker (hacking around the mess of binary software distribution on Linux). I don't want to spend my time learning workarounds.

gojomo 6y ago
But, it's a "hack workaround" that a professional consensus has converged upon. Pythonistas have developed supporting tools & help-texts, & many assume the use of silo'd virtual environments as 'basic hygiene' for serious work. The approach is also highly analogous to other "alternate virtual root" solutions across OSes/containers/user-customization schemes. So instead of that, you'd rather... make you own custom hack workarounds? That will be idiosyncratic to your installations/projects? That will hit unique errors/tradeoffs the standard convention has already worked around? That will be harder for others to understand? OK, to each their own!