If you are having problems with pipenv, try poetry. It’s modeled after things outside the python ecosystem (to me) and it’s worth a look. On one project, I had pipenv not able to solve the dep tree and poetry did solve it. And remember, these packages come from the same pypi source.
This is just an aside, not arguing the OP’s point of Nix as a universal cache or locking mechanism. I just think the smaller step would be to try poetry. I has almost nearly zero cost. I made a requirements.txt file out of pipenv and then just did poetry add for each line.
I think poetry would also address the original problem of not bumping all downstream dependencies and just the ones you need.
That definitely sounds like a smaller step. The main reason that I have no desire to do it is that it would be a Python-specific step. I’ve used enough languages that I don’t really have patience for learning their idiosyncratic dependency management systems. Of course, for people who primarily identify as Python programmers, sticking with the traditional Python tools makes sense.
We recently decided to go the other way, from Poetry to Pipenv. Our problem is that we mainly target Raspberry Pi and can’t get the particular dependencies pulled as binaries on ARM, instead we waste a lot of time compiling. We tried all sorts of settings in our pyproject.toml that didn’t work. Switching to Pipenv looks like it will solve it.
+1 for poetry. It’s made python development much less unpleasant for me. And, poetry2nix is pretty awesome, making packaging python projects with nix even easier 😁
Nix is the dream of an ultimate DevOps toolkit in a similar way as Haskell is the dream of an ultimate programming language. Neither of these dreams seem to be congruous with reality.
I definitely felt that way with Nix - that the promise did not live up to reality. Haskell on the other hand does give you the things it promises, but convincing others (founders, VCs, managers) that it’s worth writing the stack in is near impossible, which means that the ecosystem get stunted. It’s a bit of a cold start problem.
Going into more detail about Haskell specifically - non-traditional languages like Haskell are often the “weird thing in the room”. When something goes wrong humans often look at the first weird thing in the room to blame, regardless of whether or not it deserves that blame. The result is that many commercial Haskell projects get re-written in another more common language at the first sign of ANY corporate turbulance.
I’ve had these discussions numerous times. Nobody ever cares about supporting evidence – they (we?) just flat out reject it if it doesn’t match their preconceptions or flat out accept it if it does. So I don’t bother with it anymore.
I think I may have misunderstood your original comment.
Generally people intuitively believe that Haskell is “unrealistic” and only suited for “academic” projects. Some even go so far as to say that people writing in Haskell tend to be “elitists”. In fact, I used to tacitly (with no fault of my own) believe that; it is basically the general impression the tech community holds collectively.
All of that of course turned out to be utterly false, once I started using Haskell for work and real projects. The real question is - how do we educate the community about what is factual?
As someone who was swept up in the hype of both of these, this comment hits too close to home. They still have their use cases and offer advantages not seen in many other places, but they are certainly not for every user nor every task.
Say, for example, you want to have Postgres and Redis available on CI to run some integration tests. With most other systems, you would have to set this up yourself with some bash and duct-tape.
Nope. With most CI systems, you just declare these two as dependencies for a given task, and you’re good. If your CI forces you to write shell scripts to manage runtime dependencies, maybe it’s not a very good CI. Etc.
It’s a good article, but I feel that a lot of what nix had set out to solve has been solved differently. It’s not to say it is useless, I do think it’s great, just like I think that Haskell or Rust are great, but I’m not going to throw away things that just work, because it’s cool.
If you are having problems with pipenv, try poetry. It’s modeled after things outside the python ecosystem (to me) and it’s worth a look. On one project, I had pipenv not able to solve the dep tree and poetry did solve it. And remember, these packages come from the same pypi source.
This is just an aside, not arguing the OP’s point of Nix as a universal cache or locking mechanism. I just think the smaller step would be to try poetry. I has almost nearly zero cost. I made a requirements.txt file out of pipenv and then just did
poetry addfor each line.I think poetry would also address the original problem of not bumping all downstream dependencies and just the ones you need.
That definitely sounds like a smaller step. The main reason that I have no desire to do it is that it would be a Python-specific step. I’ve used enough languages that I don’t really have patience for learning their idiosyncratic dependency management systems. Of course, for people who primarily identify as Python programmers, sticking with the traditional Python tools makes sense.
We recently decided to go the other way, from Poetry to Pipenv. Our problem is that we mainly target Raspberry Pi and can’t get the particular dependencies pulled as binaries on ARM, instead we waste a lot of time compiling. We tried all sorts of settings in our pyproject.toml that didn’t work. Switching to Pipenv looks like it will solve it.
+1 for poetry. It’s made python development much less unpleasant for me. And, poetry2nix is pretty awesome, making packaging python projects with nix even easier 😁
Nix is the dream of an ultimate DevOps toolkit in a similar way as Haskell is the dream of an ultimate programming language. Neither of these dreams seem to be congruous with reality.
I definitely felt that way with Nix - that the promise did not live up to reality. Haskell on the other hand does give you the things it promises, but convincing others (founders, VCs, managers) that it’s worth writing the stack in is near impossible, which means that the ecosystem get stunted. It’s a bit of a cold start problem.
Going into more detail about Haskell specifically - non-traditional languages like Haskell are often the “weird thing in the room”. When something goes wrong humans often look at the first weird thing in the room to blame, regardless of whether or not it deserves that blame. The result is that many commercial Haskell projects get re-written in another more common language at the first sign of ANY corporate turbulance.
That’s certainly a strong claim with no supporting evidence in response to a post with supporting evidence.
I’ve had these discussions numerous times. Nobody ever cares about supporting evidence – they (we?) just flat out reject it if it doesn’t match their preconceptions or flat out accept it if it does. So I don’t bother with it anymore.
I think I may have misunderstood your original comment.
Generally people intuitively believe that Haskell is “unrealistic” and only suited for “academic” projects. Some even go so far as to say that people writing in Haskell tend to be “elitists”. In fact, I used to tacitly (with no fault of my own) believe that; it is basically the general impression the tech community holds collectively.
All of that of course turned out to be utterly false, once I started using Haskell for work and real projects. The real question is - how do we educate the community about what is factual?
As someone who was swept up in the hype of both of these, this comment hits too close to home. They still have their use cases and offer advantages not seen in many other places, but they are certainly not for every user nor every task.
Nope. With most CI systems, you just declare these two as dependencies for a given task, and you’re good. If your CI forces you to write shell scripts to manage runtime dependencies, maybe it’s not a very good CI. Etc.
It’s a good article, but I feel that a lot of what nix had set out to solve has been solved differently. It’s not to say it is useless, I do think it’s great, just like I think that Haskell or Rust are great, but I’m not going to throw away things that just work, because it’s cool.