Please speedup Pipenv

[timkofu]

In a project with about 10 prod deps, pipenv install took about 10 minutes. Then we added jupyter, scikit-learn, andtensorflow and it ground to a halt. Over an hour later, it was still "locking". pipenv lock --clear didn't help.

We switched to pip and it installed all the deps in a couple of minutes. We reckon pipenv needs to be at-least as fast as pip in all operations, as dev time is valuable. We can all agree an hour waiting for an operation is not justifiable, especially for a tool as handy as pipenv.

[uranusjr]

Sounds like a good enhancement. I look forward to your contributions!

[timkofu]

I look forward to your contributions!

Oh yes, glad to help. Where can we find the sequence diagram of what happens when pipenv lock is run? With that we can give it a go when time allows, or others get here and have time to give it a go.

Sounds like a good enhancement.

It's a non-functional requirement yes, but quite a popular one (#356, #1914, #2873, #4260, on SO, on HN).

[ZelphirKaltstahl]

Oh yes, glad to help. Where can we find the sequence diagram of what happens when pipenv lock is run? With that we can give it a go when time allows, or others get here and have time to give it a go.

Ah, the wonderful world, in which people document the approaches and algorithms they implemented in software to solve the problems and visualized it nicely in a standardized way, so that people have a good time getting into the code base of the implementation … Oh wait, that was another universe. I'm outta here!

Anyway, in more serious terms: It always astonishes me, how huge projects with many contributors can be so little documented, that the answer to "How do i get started?" seems to be to read the code or a measly API doc, which was generated from comments, which have no information gain for the reader like:

def example_say_hello():
    """Say hello."""
    print("hello")

Pipenv would gain a lot, if people, who know the code base, created the UML models and put them in docs or at the very least describe in detail the approaches the code implements in simple language, to make it accessible. At https://docs.pipenv.org/ I cannot find anything about how to start developing / hacking pipenv. Guess it is RTFC ("read the f. code!") again. It would make it stand out compared to the many projects, which do not do this.

I sometimes do this on the job and I work in a < 10 developers group. Yes, documenting things takes time, as does writing good comments in the code (not comments like the "say hello" in the example above). Sometimes more than coding the solution to the problem. It will save many hours of getting familiar with the code for newcomers / contributors later. I would even go so far as to say: Stop all other work on the project and start documenting for developers, until a certain coverage is reached. This will be the most beneficial thing possible to do for the pipenv project.

[LegoStormtroopr]

Sounds like a good enhancement. I look forward to your contributions!

The difference between PipEnv 2018.11.26 and PipEnv 2020.x.y is well documented. Obviously something changed dramatically. Taking the very snarky approach of "well its open-source, fix it yourself" is fine for small libraries, but doesn't fly for what is supposed to be the official python packaging solution.

Not everyone has the ability to directly contribute back, but your attitude will make sure they contribute in one of two ways:

• word-of-mouth: if you treat your users with some respect, they will either promote your software... or advise others against it
• offer feedback: user feedback isn't always nice or thorough, but its always educational. You are getting feedback because your software is being used. Listen to that feedback, or you may find there won't be users to give feedback in future.

[frostming]

Thanks for the kind advice given above, I would like to close this issue in favor of #4430

[timkofu]

Listen to that feedback, or you may find there won't be users to give feedback in future.

After the “do it yourself” snark above, we decided to give Poetry a try. It has none of the speed issues, and has so far been a pleasant experience getting it to the same functionality pipenv was giving us. Also from the pull request and issues responses, one can tell the devs are about improving DX, which makes it a nice package to associate with.

Not everyone has the ability to directly contribute back

As we know anyone can learn anything, all they have to do is start and not stop. Programming is no exception, and the age thing is just yet another gaslight. So it’s really about whether one is willing to spend their time contributing to the project, and detailed design docs are developer in-groupism, an unspoken welcome to software engineers; shows your time and effort will be respected.