-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pipenv ignores conflicts between default and development dependencies #1137
Comments
This is actually sort of a structural weakness with the current As a workaround, probably resolve default dependencies first, then use the pip-tools caching repository, and fail if any development dependencies resolve to different versions. |
This is biting me this morning with Django 2.0 being released over the weekend.
Since debug toolbar has a requirement of "django>=1.8" it separately matches "django==2.0" which of course causes a problem on Python 2.7. If For others hitting this, my workaround for now is add Edit: Error I was getting is |
Note pypa/pipfile#100, which is the root issue here. The lockfile format should structurally prevent this, and there is prior art here showing how to avoid this. |
This sounds kind of related to my problem: Have a look at the pipfile:
And the broken result - notice that ie Django and BeautifulSoup are included twice:
|
intended behavior |
Hi @kennethreitz , so does that mean that things like Django version constraints are should be duplicated between the [dev-packages] and [packages]? Failing example based on @jsatt 's from #1137 (comment) , with pipenv==9.0.1 Pipfile:
Which seems wrong - I would expect [packages] to act as a constraint on [dev-packages]. Adding the django version explicitly to [dev-packages] does resolve this, but it seems like unnecessary duplication. Pipfile with duplicated Django version
Can you confirm? |
this is really terrible intended behavior. You'd think an ecosystem that desperately struggles from terrible dependency management would be a bit more open to doing what literally all modern package managers do instead of insisting on being special and different. |
we may strive to improve this in the future, but that's far down the road from now, based on the way things are built currently |
believe it or not, these tools are complicated, and such a feature request is far from trivial. if you'd like to contribute code to fix this, please do so. |
Can you clarify, then, whether this is an intentional design decision or not? pypa/pipfile#100 |
I'm sure more people would be willing to contribute if reasonably detailed issues documenting suboptimal behavior (and asking if it should be different) weren't closed with single sentence responses claiming the behavior is working as designed |
@jquense it may be closed with only a single sentence but there is significant internal dialogue about how to handle these kinds of issues. This is ongoing and we are continuing to discuss |
This really isn't the first time issues here with significant UX implications have been closed with minimal feedback, and no indication on whether PRs are welcome, or whether the current behavior is as intended: #966 These really aren't even difficult things to do – a fairly thin wrapper around the stuff that's already available in pip-tools is sufficient, and we've built proof-of-concepts internally that don't make people who have used other locking package managers scratch their heads in confusion wondering why Pipenv does weird things around managing dependencies that aren't what people expect. ... meanwhile, Pipenv does stuff nobody really asks for like bundling Flake8. It's not like the community isn't able or willing to submit PRs here, but closing the issue with:
And then saying:
... really makes me far more inclined to build a better version of this tool that's driven by actual experience with good package managers that I enjoy using. You are violating your own code of conduct here: https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way |
I think nobody argues about package management being difficult to implement. It’s just the comment that should have said: expected behavior due to current design decisions And it should point to a well documented issue where the cause of this is explained so that people might be able to jump right in and fix it, because it sounds like @kennethreiz kinda knows why this is happening. And I still refuse to believe pipenv is actually intended to work that way! So for my part I read „currently intended behavior - about to change, but may not that soon“. Thanks for the good work so far. And please open a known issue ticket yourselves so that people know about you internal discussions rather than reading that you ignore kinda serious problems. Im willing to help out here. Please give us some hints! |
To be entirely clear here, you can get a sense of how involved we've been in the OSS community from our GH profiles – and that's in using, maintaining, and contributing to projects. I don't believe I've ever had as intensely unpleasant experiences with anybody in OSS as with @kennethreitz in my three brief interactions with him:
And that includes the time I, as a maintainer, made a hostile fork of a project with something like a million downloads a month. |
Maybe another person wrote the code of coduct and he just posted it without even reading it .. i like the essay! Maybe its just time for a little time off to lower the general annoyance level? |
@taion i'm sorry you feel you've had negative experience by my lack of verbosity when responding. There are dozens and dozens of tickets to respond to, and I have a limited amount of time. None of my responses were non-cordial, they were simply terse. There's a big difference. This is a free project done by volunteers who are extremely constrained on time. Contributions are much more welcome than requests for changes, which is why these issues keep getting closed. We're having a hard time keeping up, at the moment, with our small team (which is growing), and we have to pick and choose our battles. Pipenv strives to be an ideal tool, and in many ways, it is. But, if we cater to every incoming request with either allowance or excruciating detail of why we aren't going to persue that option at this time, we'd have no time to work on the code itself. If you'd like to help contribute to this project, please do so! |
@taion another reason why details aren't given is because they simply aren't available at this time — if we had all the answers for the future, we'd either be implementing it or sharing it when appropriate. When terseness is present, it is because the future is unclear, the feedback is noted, and we will continue to toil away at the tool to improve it and iterate on it as we best see fit. This is a project done by individuals, not a piece of software owned by a community that is responsible for it's direction. We, the maintainers, and I, the creator of this project, are solely responsible for the direction of this project and its future, and all feedback given is appreciated. But it is simply that — feedback. A closed issue doesn't mean a solution will never come. It simply means it's off our immediate to-do list. |
I'm sorry, but your behavior is simply not consistent with your claims. The point of these issues is to solicit feedback from the community on what the correct behavior simply is. As a project maintainer, it's your responsibility to give a better answer than
when asked about questions like #966 (comment). Certainly it's within your right to say in cases like pypa/pipfile#100 (comment) that
but this is simply an extremely unsatisfying answer, given that your design there has directly caused this bug, and that it's contrary to how the other locking package managers on which you've modelled Pipenv work. You've been around long enough to know how external contributions to OSS projects work, I hope. They don't work by closing discussions with "we're not going to fix this". And claiming that it's
is not just terse, it's dismissive and borderline rude. |
Hey so I ran into this issue this morning with the Django thing, I think this bug might have a pretty widespread impact because Django/django-debug-toolbar are a really common pairing and for all the people on 1.8/1.11 and py2 which are both still in LTS are going to run into this: pip.exceptions.InstallationError: Command "python setup.py egg_info" failed with error code 1 in /var/folders/0b/phw6chc96r78hqbm56c0_w4r1ft3hs/T/tmpCbp0tabuild/Django/ and not really have any idea what is going on. As an experience python dev it took me half an hour to find this issue in the github issue tracker, a new pythonista who is using the pypa recommended pipenv will likely just be discouraged and frustrated. Perhaps an immediate to-do is to provide an error hint when this situation occurs and a link to documentation of how to fix it (mirroring packages in both dev and regular packages). |
I have no responsibility to anyone, I am giving away free software that you are free to use or not. Please take your attitude elsewhere. Pipenv was not modeled after bundler, npm, yarn, cargo, composer, etc. But it took inspiration from them. It is in no way responsible for making the same design decisions they do. In fact, it seeks to do the opposite, in many cases. It is important to remember that this ball is already rolling, making sweeping changes to the fundamentals of how things work at this point is out of scope, until our new senior developer, @ncoghlan joins the team next month to start taking the project "up a knotch". Until then, you're going to have to be content with the (imo, excellent) software with which you are provided, even if it has quirks. Don't demand perfection, especially from volunteers. This shit is stressful, believe it or not. |
@audiolion install pipenv with python3. The documentation now makes this pretty clear, but we could do a better job of saying so. |
@kennethreitz just out of curiosity: wouldnt it be more helpful for a known 'bug' to stay open so that people can find it? And i think you agree that it is a bug. |
If you are planning on running this project like a personal hobby project (you definitely can!) please don't also try and be the recommended packing solution for all of python. You of course can do whatever you want, but its silly and naive to think that people should expect nothing from you in terms of project management, attitude, or governance, while also trying to provide defacto standard core tooling for an entire PL ecosystem. Its frustrating to see a much need thing being designed and managed by folks so embedded in their corner, that they are intent on ignoring the collective work of many folks in this space, as well as legitimate attempts by folks to contribute, turned away |
Good luck. |
As I said, the team is expanding, and we'll have more bandwidth in the coming months to take a different approach. Until then — be patient. |
@kakulukia if you think that's a good idea (which it is), please send a pull request adding a TODO file :) |
FYI this thread inspired me to write two posts today: |
@kennethreitz no you misunderstood me there .. i dont mean that anybody should be involved in managing a todo list. And those labeld tickets will BE the always up to date todo list (missing a priority tho). Plus the added bonus of people not creating duplicates (fi they search first - i know its hard some times :D) or being able to maybe find a workaround or help tracking down the cause of the bug. Because that ticket being closed probaly wont catch my attention while im searching for ways to contribute. |
Thanks for the reads @kennethreitz , I think if people read these it will help them empathize with your situation. I won't deny that I have been frustrated by the terse responses or the closed issues with no comments before, but I also know that you are doing this with your own free time and have so much going on so when I consider that it is easy to quell those feelings and try to be respectful as possible.
|
@audiolion That's a very solid proposal. Pipenv is definitely an improvement over using pip on its own, but as-is the experience is not really satisfactory compared to just using pip-tools directly. |
Or, you could, you know, offer to join the team :) |
I'd be happy to submit PRs, but as-is you haven't provided any actionable feedback on ways to proceed. So I'll ask again – what is the intended behavior here, in #966 (comment), and in pypa/pipfile#100? I'm not asking you to code these features. We're fully capable of doing that on our own – but as the project maintainer, the onus is on you to say what the intended behavior actually is. |
Ditto ^ |
You guys just don't take a hint do you? |
While I'm not fully back from vacation yet (and won't be until next week), I've posted a proposal at #1255 that should allow these conflicts to be detected when installing the dev packages, while still respecting the underlying architectural limitations that make it difficult to re-use the dependency flattening techniques adopted by other ecosystems. |
i just took a stab at this fdebdc3 |
should be fixed in master |
Describe your environment
Python 3.6.3
pipenv, version 8.3.1
Expected result
Suppose I have a default dependency that depends on
six==1.10.0
and a development dependency that depends onsix==1.11.0
.I expect to get some sort of error here, because it's impossible to satisfy both transitive requirements simultaneously.
Actual result
Pipfile.lock
is great, too, featuring:Steps to replicate
The text was updated successfully, but these errors were encountered: