Skip to content
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

new command to support more options #5710

Closed
wants to merge 23 commits into from

Conversation

juhoautio
Copy link
Contributor

@juhoautio juhoautio commented May 27, 2022

Adding all the missing options that are asked interactively by the init command.

Also improving & fixing the doc of init command to match.

Question: How to validate the rendering of docs/cli.md (especially the relref)?
-> Answered in #5708 (comment)

Question: Is it on purpose that mypy is not part of the pre-commit hooks? My 1st push failed on CI because of a mypy error because I didn't realize I should've ran it manually.
-> Answered in #5710 (comment)

Pull Request Check List

Resolves: #1854

  • Added tests for changed code.
  • Updated documentation for changed code.

Adding all the missing options that are asked interactively by the init command
@Secrus Secrus added the area/docs Documentation issues/improvements label May 28, 2022
@github-actions
Copy link

github-actions bot commented May 28, 2022

Deploy preview for website ready!

✅ Preview
https://website-67l9ix9lp-python-poetry.vercel.app

Built with commit 16caa17.
This pull request is being automatically deployed with vercel-action

@neersighted
Copy link
Member

Question: Is it on purpose that mypy is not part of the pre-commit hooks? My 1st push failed on CI because of a mypy error because I didn't realize I should've ran it manually.

Yes, it is for now. mypy was part of our pre-commit hooks but we can't run it in the correct environment without duplicating our list of dependencies. We are probably going to set it up as a tox environment and then suggest running tox to trigger pytest and mypy.

Copy link
Member

@neersighted neersighted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very enthusiastic about subclassing the init command -- instead, I would prefer to see the common parts of both commands factored out into shared helpers. Also, let's drop the -l short option for --license as it's inconsistent and it was never documented.

@juhoautio
Copy link
Contributor Author

There are some existing commands that inherit the InitCommand. Should those be also detached by extracting shared helpers? Maybe not yet in this PR though.

@juhoautio
Copy link
Contributor Author

Also, let's drop the -l short option for --license as it's inconsistent and it was never documented.

Added in commit 7d578a1.

I would prefer to see the common parts of both commands factored out into shared helpers.

Done in commit a09c47b.

@juhoautio
Copy link
Contributor Author

@neersighted is this ok? or something to improve still?

@juhoautio
Copy link
Contributor Author

@neersighted I tried to address the review comments but looks like this PR was forgotten and there are some conflicts to be resolved. Those should be easy to fix, but would it be possible to have a review for the commits that I added since you last checked this?

@neersighted
Copy link
Member

Hi @juhoautio -- the maintainers are busy people doing this in their spare time. While an occasional ping (especially to those who have already interacted with a PR/issue) is not unwelcome, pinging people who have not expressed interest in an issue or reviewing code, without a prior understanding of what they are interested in helping with, is generally considered rude. Likewise, pinging repeatedly is generally considered rude.

Additionally, Github as a 'request review/re-review' feature that is generally used for this and makes it easier to reason about what reviews are left on your to-do list as a contributor with many priorities.

Most reviewers will not take a look at code that is conflicted and failing tests as non-mergable code must, by its nature, change (often substantially) in order to be accepted. Thus reviewing it is generally a waste of time for all parties involved. I am sorry that I did not comment that here -- hopefully that explanation/expectation helps in the future when you request reviews.

@juhoautio
Copy link
Contributor Author

Sorry! I had not noticed that there's a Re-request review feature, or at least didn't remember. I'll use that from now on.

I'm also very sorry that I ended up using desperate means like pinging another maintainer. In fact I wasn't sure how to best raise my question about what I should be doing next without appearing rude, yet I failed at it. In the end, I now have the guidance that I was looking for. Thanks a lot for that.

@juhoautio

This comment was marked as outdated.

Copy link
Member

@neersighted neersighted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good to me, but I'm not sure about the addition of --dev-dependency while we're moving away from --dev. I think we should either generalize it to any group, or just drop it in general as it's going to be pretty niche during new.

@juhoautio
Copy link
Contributor Author

Should the existing --dev-dependency option of init be deprecated?


How about having a new option --group-dependency for both init and new? The value format could be GROUP:DEPENDENCY.

e.g. dev:requests:^2.10.0 or dev:requests=2.11.1 or dev:requests.


or just drop it in general as it's going to be pretty niche during new

The ability to set dev dependencies with new is needed for my use case. Or then I would like to have an option for add that allows only modifying pyproject.toml without updating poetry.lock.

@neersighted
Copy link
Member

I think the best move is to drop the --dev-dependency change from this PR, and then introduce a new PR deprecating --dev-dependency on init and adding --group-dependency using the design you've proposed.

Copy link
Member

@neersighted neersighted left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more tweaks -- there is a lot of moving code around in this PR in the same commit it was changed, so it's a bit hard to review.

I think we should block this on #6669 as the new AbstractRepository introduced in that PR will make all the functions that currently take Pool (which just has PyPiRepository in it anyway) much cleaner and allow for dropping Pool until such time that we actually support searching sources other than PyPI.

@@ -88,3 +134,12 @@ def handle(self) -> int:
)

return 0

def _get_pool(self) -> Pool:
if isinstance(self, EnvCommand):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check makes no sense given the type of the command.

return result


def create_pool() -> Pool:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's drop this helper and keep things inline -- it's less messy than stashing this helper in such an obscure place, and this isn't the PR to solve the ergonomics of creating the pool in anyway. If you want to clean things up and be a bit more specific, you can just use PyPiRepository.search() instead of creating a pool with one repository.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to clean things up and be a bit more specific, you can just use PyPiRepository.search() instead of creating a pool with one repository.

I'm all for cleaning things up, but not sure what it means to replace this with PyPiRepository.search() -> moving the code inline. Also, good to avoid additional refactoring in this PR's scope.

@juhoautio
Copy link
Contributor Author

juhoautio commented Oct 10, 2022

there is a lot of moving code around in this PR in the same commit it was changed, so it's a bit hard to review.

This is unfortunate, yes. The commit to blame for most of the refactoring is a09c47b. In that commit I am only moving the existing code to functions but not changing it otherwise.

I think we should block this on #6669 as the new AbstractRepository introduced in that PR will make all the functions that currently take Pool (which just has PyPiRepository in it anyway) much cleaner and allow for dropping Pool until such time that we actually support searching sources other than PyPI.

Looks like that PR was already merged 🎉 I'm sorry but I couldn't figure out what it would mean in practice for this PR, how to replace Pool with AbstractRepository in these functions? I was about to take AbstractRepository in find_best_version_for_package but it ends up using VersionSelector(pool). Is it possible to change the signature of VersionSelector to take AbstractRepository instead of Pool?

I committed something along these lines, curious to hear the feedback (commit b3e5364). But I rolled it back because it seemed to be trying real PyPI calls and made the build fail on Travis. I would also like to omit it to keep this PR simpler.

@@ -528,7 +528,7 @@ def find_latest_package(
return provider.search_for_direct_origin_dependency(dep)

name = package.name
selector = VersionSelector(self.poetry.pool)
selector = VersionSelector(self.poetry.pool.repositories[0])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the right way to handle this? Moving from Pool to AbstractRepository.

@finswimmer
Copy link
Member

@juhoautio: Sorry I'm late to the party. I think we should rework the implementation of poetry new and poetry init in that way, that poetry new becomes an extended version of poetry init. Doing this we can makes sure, that new have at least the same options as init, even if we introduce a new option.

This is why I closed the issue you've linked in your PR description. The new "major" ticket should be #2563 now.

@juhoautio
Copy link
Contributor Author

@finswimmer is someone (you?) going to work on implementing #2563 some time soon? If yes, does that means this PR is rejected after all? But if no one will work on #2563, I would still hope to have this PR merged with the current scope ie. just adding some missing options & fixing some docs without any bigger refactoring.

@finswimmer
Copy link
Member

Hey @juhoautio ,

this doesn't mean your PR is rejected. The scope is not that far away from #2563 and I was hoping that you maybe like to go that extra mile. :)

fin swimmer

@juhoautio
Copy link
Contributor Author

I could work on it if you'd like, but if the design changes that much, I think starting from a clean slate with a new PR could be better. I would hope to have some guidance on the desired approach for implementing it. Please let me know.

I'm still wondering if this PR could be finished because it's almost there. Maybe I'm also missing what additional use cases the new alternative will enable compared to this.

@Secrus
Copy link
Member

Secrus commented Mar 3, 2024

Superseded by #9088

@Secrus Secrus closed this Mar 3, 2024
Copy link

github-actions bot commented Apr 3, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/docs Documentation issues/improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

poetry new to support --dependency & --dev-dependency
4 participants