I wonder if the team would be open to removing "for humans" references. Here are my personal thoughts on the subject, collected from a blog post I wrote a couple years ago.
People use the for humans meme so frequently on projects that it's original intent and meaning have been obscured, leaving only a meta-meaning -- which is no meaning at all. When I see it today, I only see the other person trying too hard to signify that they are "in". It is the opposite of some people's tendency to obscure things in jargon, but they both derive from the same underlying impulse.
There's also a whiff of self-deprecation implied, "X is difficult, so here's something for humans". But of course in order for a project to be useful, the maintainer must have a command of the subject, so it comes off as a show of false modesty.
When a new project comes out describing itself as X for humans, it somehow implies that any other libraries existing in the X space before were somehow not for humans. Since for humans is meant to connote sympathy for the developer, this label implies that other packages were not developer-friendly. In other words, it's a bit of a backhanded dig at other libraries for having bad APIs.
The audience for any Python project is always going to be a developer somewhere. To call your project For Humans is just a pretentious way of saying that you see your project as having a superior API to other projects in the same space.
Let the library speak for itself. Let others be the judge of it's quality.
I'm curious to know the pipenv teams' thoughts.
This tag line is basically synonymous with Kenneth. It may be obvious _now_ that software is for developers, but the reason the tag line exists is because a lot of software is written and designed without consideration for that fact.
Pipenv is not unlike requests— it’s a bit more opinionated, but it’s in a more controversial space. We target the use case of someone who comes from another language like JavaScript or PHP and is accustomed to a lockfile and an environment manager all in one. We also target the new developer who doesn’t know about virtualenvs and for whom tracking and remembering activation, accidentally installing things system wide, losing track of dependencies, etc, pose significant challenges which have nothing to do with the problems they are looking to solve. By asking them to be familiar with many tools before they even begin developing, we have already created a significant amount of cognitive overhead which can be a turn-off.
Obviously previous tools had many use cases in mind, and evolved with the ecosystem. This tool has the advantage of being new and unifying those tools with added functionality.
The distinction here is that we are interested in the user experience before added features. Unfortunately software doesn’t speak for itself, and when you have a brand and your goal is in line with it, sometimes it makes sense to use it.
I don't want to debate the usefulness of pipenv in this issue. I hoped to express my opinion that for humans has an egotistical, hollow ring to it (which is just my own opinion). Attempting to parlay the success of requests in order to push new tooling strikes me as a bit dishonest. requests (while being a fantastic library) is a 100% different codebase than pipenv. Applying "for humans" in the tagline to requests was, to my understanding, a reference to the clumsy APIs available through urllib and httplib at the time. Packaging, as you mentioned, is more controversial for sure, and I don't have any desire to debate the usefulness of pipenv. It seems to me that the more honest approach would be to let pipenv speak for itself. If it is truly useful then it should see adoption.
This tag line is basically synonymous with Kenneth.
Agreed, it's a way for him to brand his projects, which is his choice. But I think we can all agree it doesn't provide a technical description, but rather is more for marketing. And I think this brings up a bigger question: since Pipenv is now owned by pypa, an authority which I think we all hope is impartial and hopes only to get users the right information without bias or self-promotion, does it make sense to leave such marketing/branding in the description? Maybe this is a question more appropriate for https://github.com/pypa/python-packaging-user-guide.
the more honest approach would be to let pipenv speak for itself. If it is truly useful then it should see adoption.
+1
It is seeing adoption, that doesn't mean that we can only write completely flat-toned, non-promotional, purely technical documents about it. Sorry, I realize there is a lot of negativity and the desire to push back against this, but we are allowed to promote our own tools and use our own brands. We are also volunteers and interested in enjoying ourselves while we work. Nothing about our participation in the PyPA mandates that we speak in pure monotone and technical specification.
In short, I'm not really interested in entertaining this kind of suggestion -- the honest approach is that we are allowed to market a product, and we are also allowed to build that product and simultaneously be part of the packaging authority. We can be opinionated while doing all of these things and continue to use the branding of the person who designed the API behind it and whose idea it was to make this tool in the first place.
for the record I googled 'npm' and their landing page has a giant thing that says 'build amazing things' and no technical documentation until you scroll down a bunch. So while I agree the project should speak for itself, I'm not really sure what that actually means or why it excludes promotional or opinionated material. At the end of the day it describes the guiding philosophy (as compared with building things to solve technical challenges, or because some company paid you for it, etc).
Packaging, as you mentioned, is more controversial for sure
I don't think anyone believes python packaging is in a good state. New users are expected to learn 3 different tools at a minimum to just install something, and if you don't first set up your path, locales, etc, you might wind up cross-pollinating your system with different versions of things and horribly breaking your installation before you've ever written a line of code. This is not a good situation.
The brand was built when requests was built, and now it exists and it describes not just a negative ('this stuff is bad over here'), but instead a philosophy behind API design in general. And no matter where this project lives, that philosophy is probably going to go with it, and so will the branding.
doesn't mean that we can only write completely flat-toned, non-promotional, purely technical documents about it.
That's a straw-man and completely trivializes what I was saying. My comments make clear that I never suggested anything of the sort. I suggested dropping the "for humans" tag-line (only) and gave several reasons why. What you've said is just plain dishonest.
we are allowed to promote our own tools and use our own brands
Absolutely. I have no desire to try and force anyone or otherwise compel you to change the project. I made my point, and I appreciate your willingness to listen and respond, whether or not you agree.
I don't think anyone believes python packaging is in a good state... This is not a good situation.
Again, I explicitly said that I had no desire to debate the usefulness of pipenv or the state of packaging in general. Did you miss that?
I'm not really sure what that actually means or why it excludes promotional or opinionated material.
Again, this is dishonest. I thought I made it clear this was only about the phrase "for humans" and had nothing to do with self-promotion or opinions expressed in the docs.
All that being said, I appreciate you taking the time to hear me out and of course I respect your decision to close this. Thanks for your time.
This tag line is basically synonymous with Kenneth.
This speaks to a larger issue - is pipenv a Kenneth project or a PyPA project? Because right now it looks like PyPA should be in charge of it, but aren’t.
And given the confusion about how official this project is, that needs to be cleared up for the community’s sake.
@LegoStormtroopr this is both a Kenneth project and a PyPA project. The PyPA isn't 'in charge' of anything besides the organization itself, individual volunteers maintain each individual project in the PyPA which is a loose collective and always has been. People demanding that the PyPA stand up and order anyone to do anything have a broad (but understandable) misunderstanding about how the packaging authority operates.
The confusion has been addressed with changes to the documentation we are beginning internal discussions about how to organize the PyPA more broadly (which was happening long before anyone opened an issue on here). The tagline, however, was associated with the project and the project team way before we moved to the PyPA, and simply moving a project under the umbrella of the packaging authority doesn't mean that everything about the project now conforms to a 'technical documentation only' standard.
As for previous comments about my being dishonest, I was addressing multiple comments from more than one person, and even from more than one source. As a maintainer of a large project, sometimes I have a responsibility to hear an individual issue and understand how it fits into a broader scope of relevant discussions, so I reply to more than just one person or one thing when I answer. If you were looking to have productive discussions on a topic, calling me dishonest for following some lines of reasoning would be an example of a good way to avoid productive discussion.
It's clear from the tone of this issue that it actually _can't_ be productive, because the nature of it from the outset is basically 'I don't like that Kenneth Reitz and his tagline are associated with this project and I don't believe that it should be allowed, and I want the packaging authority to stand up and do something about it.' My answer to that is basically just one word: No. It's a tagline, I find it really hard to imagine that this is causing any problems for anyone. We aren't really open to any further input on this.
Most helpful comment
Agreed, it's a way for him to brand his projects, which is his choice. But I think we can all agree it doesn't provide a technical description, but rather is more for marketing. And I think this brings up a bigger question: since Pipenv is now owned by pypa, an authority which I think we all hope is impartial and hopes only to get users the right information without bias or self-promotion, does it make sense to leave such marketing/branding in the description? Maybe this is a question more appropriate for https://github.com/pypa/python-packaging-user-guide.
+1