5 ms·

Somehow pipenv got endorsed as an official tool by PyPA far before it was ready for production. The documentation for pipenv and Python packaging didn’t make it

Somehow pipenv got endorsed as an official tool by PyPA far before it was ready for production. The documentation for pipenv and Python packaging didn’t make it clear early on pipenv was for applications, not libraries. Also the pipenv maintainers were very rude about closing bugs. This has lead to a lot of reasonable criticism about the tool and how it’s maintained. Despite marketing the tool heavily, Reitz is taking all of this personally and is blaming others or his mental issues. Now, Reitz has posted this 3 times on /r/python in the past 2 days, and hosted a hangout while also saying he doesn’t have time for criticism. And he and his PyPA buddies are all posting in all the threads and making passive-aggressive tweets. To top all this off Reitz has now made and mods /r/positivepython in an attempt to imply the original is somehow not “positive”. And in my opinion to exert more power over the python community. Before all this I really respected him, but this childish out burst will really make me think about how well design or endorsed his work is in the future.

deleted 8y ago
[deleted]
TheChaplain 8y ago
> Somehow pipenv got endorsed as an official tool by PyPA far before it was ready for production. Pretty much nails it for me. Being up to date with new technologies and tools is important, and once it became officially endorsed I (and many others) had to run with it. It was about 3 months I tried it last time, but at that time it was still slow, it ignored ~/.pip/pip.conf and also had no "proxy" CLI option like pip does. I hope it have changed now but early on it also had some strange preference to environment variables rather than CLI options, which I find odd for an application aimed for command line. I voiced my concerns about these issues, because why not? If I as a developer release something and intend to continue maintain it, I have a responsibility towards the users that depend on my creation. Old-fashioned stance perhaps...
pseudalopex 8y ago
FYI, Donald Stufft of PyPA says PyPA doesn't have official tools. https://www.reddit.com/r/Python/comments/8kjv8x/a_letter_to_rpython_kenneth_reitzs_journal/dz9btth/ https://www.reddit.com/r/Python/comments/8kjv8x/a_letter_to_...
- legostormtroopr 8y ago
  Tell that to Reitz and co who suggested otherwise: > Pipenv — the officially recommended Python packaging tool from Python.org. https://web.archive.org/web/20180228194710/https://docs.pipenv.org/ https://web.archive.org/web/20180228194710/https://docs.pipe...
  - pseudalopex 8y ago
    I think that was just Reitz, and it's been removed. But that's why I pointed out that there officially is no "officially".
    - legostormtroopr 8y ago
      PyPA (the Python packaging authority) own the `pipenv` repository on Git, and while they owned it it said "official". If it isn't official, they did a very poor job of pointing that out.
eesmith 8y ago
You write "The documentation for pipenv and Python packaging didn’t make it clear early on pipenv was for applications, not libraries." The linked-to essay says: "There is a misnomer that Pipenv is not useful for libraries. That is false. Try using $ pipenv install -e . and see what it does when you lock. It augments setup.py. I, as a library developer, find that extremely useful." I can't help but conclude that the documentation doesn't make that clear because the author doesn't think it's true.
- pseudalopex 8y ago
  Reitz is talking about development; everyone else is talking about packaging and distribution.
  - eesmith 8y ago
    I confess that I don't understand the issues. Then again, I only last month migrated my tools from 'distutils' to 'setuptools', so I know I'm way behind the times. I have just now read https://docs.pipenv.org/advanced/#pipfile-vs-setuppy https://docs.pipenv.org/advanced/#pipfile-vs-setuppy on the topic and am still confused by the terminology. Eg, "Applications are different in that they usually are not depended on by other projects." I am used to writing command-line applications which are used as dependencies for other projects. But that is neither here nor there - no need to answer. Thanks for pointing out the nuance I did not recognize.

deleted 8y ago

[deleted]

TheChaplain 8y ago

> Somehow pipenv got endorsed as an official tool by PyPA far before it was ready for production. Pretty much nails it for me. Being up to date with new technologies and tools is important, and once it became officially endorsed I (and many others) had to run with it. It was about 3 months I tried it last time, but at that time it was still slow, it ignored ~/.pip/pip.conf and also had no "proxy" CLI option like pip does. I hope it have changed now but early on it also had some strange preference to environment variables rather than CLI options, which I find odd for an application aimed for command line. I voiced my concerns about these issues, because why not? If I as a developer release something and intend to continue maintain it, I have a responsibility towards the users that depend on my creation. Old-fashioned stance perhaps...

pseudalopex 8y ago

FYI, Donald Stufft of PyPA says PyPA doesn't have official tools. https://www.reddit.com/r/Python/comments/8kjv8x/a_letter_to_rpython_kenneth_reitzs_journal/dz9btth/ https://www.reddit.com/r/Python/comments/8kjv8x/a_letter_to_...

legostormtroopr 8y ago
Tell that to Reitz and co who suggested otherwise: > Pipenv — the officially recommended Python packaging tool from Python.org. https://web.archive.org/web/20180228194710/https://docs.pipenv.org/ https://web.archive.org/web/20180228194710/https://docs.pipe...
- pseudalopex 8y ago
  I think that was just Reitz, and it's been removed. But that's why I pointed out that there officially is no "officially".
  - legostormtroopr 8y ago
    PyPA (the Python packaging authority) own the `pipenv` repository on Git, and while they owned it it said "official". If it isn't official, they did a very poor job of pointing that out.

eesmith 8y ago

You write "The documentation for pipenv and Python packaging didn’t make it clear early on pipenv was for applications, not libraries." The linked-to essay says: "There is a misnomer that Pipenv is not useful for libraries. That is false. Try using $ pipenv install -e . and see what it does when you lock. It augments setup.py. I, as a library developer, find that extremely useful." I can't help but conclude that the documentation doesn't make that clear because the author doesn't think it's true.

pseudalopex 8y ago
Reitz is talking about development; everyone else is talking about packaging and distribution.
- eesmith 8y ago
  I confess that I don't understand the issues. Then again, I only last month migrated my tools from 'distutils' to 'setuptools', so I know I'm way behind the times. I have just now read https://docs.pipenv.org/advanced/#pipfile-vs-setuppy https://docs.pipenv.org/advanced/#pipfile-vs-setuppy on the topic and am still confused by the terminology. Eg, "Applications are different in that they usually are not depended on by other projects." I am used to writing command-line applications which are used as dependencies for other projects. But that is neither here nor there - no need to answer. Thanks for pointing out the nuance I did not recognize.