121–130 of 171 posts
Earlier quoted context omitted.
Just a comment. Your command is equivalent to $ virtualenv -p python3.5 .venv
Is that true? His command would evaluate the path at the time which is run, but yours seems to evaluate the path at the time python3.5 is run. Subtle, but very different results.
> Otherwise, whatever $ which python will be the default. This is a bit strange because the python binary is always supposed to be Python 2. The Python 3 binary is supposed to be named python3. Some distributons don't follow this, but they're the weird non-conformant ones; it's not a behaviour that should really be relied on.
Earlier quoted context omitted.
pip-tools doesn't solve the problem at all. It will update things to the last up to date version, cascading from package to package. That doesn't guaranty your setup will work. Dependency management suppose to create a graph of all requirements, lower and upper versions bound for the runtime and the libs, and find the most up to date combination of those. If a combination can't be found, it should let you know that e…
How can you have an upper bound on compatibility? When a library is released, it knows that it works with version 1.3.2 with its dependency, but how can it ever know it doesn't work with 1.4, unless the developer goes back and re-releases the app?
Earlier quoted context omitted.
+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind. Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default. It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a check…
Wow, Javascript, really? I am guessing you don't actually work with NPM a lot.
Earlier quoted context omitted.
I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…
> Also notable, IMO, is the lack of a tool like rbenv or rustup for python Does pyenv not meet your needs there?
Earlier quoted context omitted.
I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…
> Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all over the place to fix paths) pip does cache the wheels so instead of moving the virtualenvs around, just recreate them. This also ensures the virtualenv is up to date. Using tox this is fairly easy to do. Sure virtualenv is a bit of a hack but it's not that bad.
Earlier quoted context omitted.
+1. Relatively to what we have before, it's so much better. But compared to the JS/Rust ecosystem, we are behind. Now it's hard to compete with JS on some stuff : it's the only language in the most popular dev plateform (the web) and it has one implicit standardized async model by default. It's hard to compete with rust on some stuff : it's compiled and is fast, can provide stand alone binaries easily and has a check…
Wow, Javascript, really? I am guessing you don't actually work with NPM a lot.
On top of all that, npm itself just does so many things right. It's quite happy to install from npm repos, from dvcs repos, from regular directories, or from anything that looks like a directory. It just needs to find a single file called "package.json". It requires no build step to prepare a module for upload to an npm repo, but it easily allows for one if that's necessary. package.json itself is basically declarative, but provides scripting hooks for imperative actions if necessary. At every opportunity, npm allows devs to do what they need to do, the easy way.
In a sense, node and npm are victims of their own quality. The types of "issues" (e.g. too many deps, too many layers of deps, too many versions of a particular dep, deps that are too trivial, etc.) about which anal code puritans complain with respect to node simply couldn't arise on other platforms, because dependency hell would cause the tower of module dependencies to collapse first. node happily chugs along, blithely ignoring the "problems".
Personally, I used to be able to build python packages for distribution, but since I've been spoiled by node and npm for several years I've found I simply can't do that for python anymore. It is so much harder.
Earlier quoted context omitted.
See my point ? There is a way to do it, it's just a pain. Now pipenv centralize stuff we were doing anyway. We should have a tool to centralize those as well.
I would hardly call it a pain, it takes me all of 3 minutes to write a .spec for most python packages and from there it's basically 'tito release'. Sure, if I wanted to package for debian-based distributions it'd take a little more time, but it's worth it to make a quality package that a distribution itself can decide to pick up (packagers love other people doing the work for them, though they won't refuse doing it t…
Earlier quoted context omitted.
I would look at this comment[0] by sametmax for a critique of pip. My main gripe with virtualenv is that it's required at all: other interpreted languages, like node and elixir for example, have figured out how to handle non-global dependencies without a third-party package. Beyond that, it's frustrating to deploy because its non-relocatable (in our build/deploy scripts at my last python job we had to use sed all ove…
> like node [...] have figured out how to handle non-global dependencies Node would be the last place I'd look for a good solution in. Not sure if there was some progress recently, but it was hell some time back. Modules were huge, taking thousands of other modules with them, majority of those being duplicates. There was no deduplication, no version wildcards I believe either. It wouldn't even work with some tools be…