Clarify arguments against Pipenv in README #488
Conversation
| populate your `setup.py` file (or `setup.cfg`) with the exact same dependencies you declared in your `Pipfile`. | ||
| So, in the end, you will still need to manage a few configuration files to properly setup your project. | ||
| Finally, the `Pipfile` is just an upgrade from `requirements.txt` and, in the end, | ||
| you will still need to manage a few configuration files to properly setup your project. |
There was a problem hiding this comment.
You will still need a setup.py in most cases, you seem to be right to remove "with the exact same dependencies you declared in your Pipfile" bit,
but other stuff required for publishing the package, describing it or setting up entry points still has to be done in setup.py.
It is also is kinda strange that you are supposed to put one part of your dependencies in setup.py and second (dev?) in Pipfile. Then why there is support for [packages] in Pipfile in the first place? I find it personally quite confusing, which makes me think that Pipfile/setup.py overlap is one of the major arguments point why would one choose poetry over more popular pipenv.
There was a problem hiding this comment.
Pipenv doesn't explicitly support libraries which is why the weird workarounds are required to get it to play nice with a setup.py. It's only designed to be a wrapper around pip and virtualenv while handling the project's dependencies. There's a nice resource about the overlap here.
There was a problem hiding this comment.
that is exactly the point of Too limited in scope argument. Adding this link would be nice too!
There was a problem hiding this comment.
I didn't mention setup.py because "a few configuration files" kind of implies it. I'm not too sure if the link would be relevant since there are more files than just the setup.py so I'd like @sdispater's input on it.
| When you specify a package to the `install` command it will add it as a wildcard | ||
| dependency. This means that **any** version of this package can be installed which | ||
| can lead to compatibility issues. | ||
| When you specify a package to the `install` command without specifying any version constraints, |
There was a problem hiding this comment.
You only reworded original text, but it seems to me like it is not exactly valid argument in the first place, as your are supposed to use Pipfile.lock when using pipenv - it is even mentioned in the next sentence! it is constrained.
But then lets say for some unknown reason (which is an edge on its own) you lost your lock and rerun from Pipfile, unless you changed default package index (again, an edge case) you will get the same or newer version... so exactly the same thing as Poetry.
Due these reasons I don't really see how this argument is valid.
I guess it would make more sense if second sentence was: This means that your dependency list alone does not reflect minimal version requirements that project has been tested against.
There was a problem hiding this comment.
The difference between Pipenv and Poetry in this regard is that by default Poetry pins the package to the latest semver compatible release. This saves you from the surprise when one of your other dependencies requires an earlier version that's incompatible with your code.
There was a problem hiding this comment.
The Pipfile.lock would save you from any potential disasters but the main point is about having a sensible default to create that lock from.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The below are about the sections I've modified, and why.
Install command
Pipenv only adds the package as a wildcard dependency if you don't specify any version specifiers. The current wording makes it sound as if Pipenv always does this. I've clarified it by explicitly stating the use without specifying any version specifiers.
Remove command
Pipenv's uninstall command seems to have been mixed up with Poetry's own remove command so I've switched them around. I've also removed the statement about
syncas it just installs packages; onlycleandeals with uninstalling any unused dependencies.Too limited in scope
Honestly I didn't know how to interpret this bit. You shouldn't have a need for both a setup.py and a requirements.txt (or Pipfile), or if you do, and for example you use the setup.py to declare the abstract dependencies your users should install and reserve the requirements.txt for the concrete dependencies only developers should install, you wouldn't have any meaningless duplication. If for some reason you'd like to have both files declare the same dependencies you could either only include them in the requirements.txt and read from it in the setup.py, or put
-e .in the requirements.txt (slightly different for the Pipfile). A good example of the first case is the discord.py library, and the requests library for the second (albeit as a Pipfile). Basically there should never be any cases where there are duplicate dependency specifications so I've removed the entire section about it.Hopefully I didn't come off as abrasive, especially for that last bit. Poetry and Pipenv are both awesome projects but I'd hate to see one get overlooked for the wrong reasons.