Skip to content

Cleanup and abstract setup.py command construction in req_install.py #2678

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

Closed
wants to merge 2 commits into from

Conversation

gvalkov
Copy link
Contributor

@gvalkov gvalkov commented Apr 13, 2015

While working on #2537 I noticed that there was some code duplication in req_install.py. I hope this change makes things a little clearer.

Review on Reviewable

@xavfernandez
Copy link
Member

Looks similar to #2579 :)

@gvalkov
Copy link
Contributor Author

gvalkov commented Apr 13, 2015

We're both aiming at the same thing - I think I'm being slightly more minimal in my approach. @msabramo, what do you think? Are you looking into rebasing #2579?

This change was part of PR #790 (link to code) but was dropped in #2537 (i.e. the re-implementation) to limit the scope of the change. That was ~2 years ago :)

'setup_py = setup_py.replace("\\r\\n", "\\n") ;'
'codeobj = compile(setup_py, __file__, "exec") ;'
'exec(codeobj)'
)
Copy link
Member

Choose a reason for hiding this comment

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

You've restructured the code here, and introduced a number of local variables, which will be visible within the exec. I can't imagine how those extra variables could alter the behaviour of the setup.py invocation, but it is a change in behaviour. I'm inclined to say to leave the injection code as it was - the readability benefit seems minimal.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right. I didn't think about all the wild cases in which a user's setup.py might break. I could mangle the names, but that would hardly be an improvement over the current:

import setuptools, tokenize;__file__=%r; exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))

I'll revert to that. Thanks.

@msabramo
Copy link
Contributor

I rebased #2579.

@xavfernandez
Copy link
Member

Related to 57db684 which was merged

@Ivoz
Copy link
Contributor

Ivoz commented Jan 21, 2016

So this no longer applies / could be closed, right?

@xavfernandez
Copy link
Member

Well, I thought there might be more to it than the setuptools shim but I'm not sure it is worth the rebase hassle, so indeed, closing this :)

@Ivoz
Copy link
Contributor

Ivoz commented Jan 23, 2016

Thanks for the good thought anyway @gvalkov , your refactoring is there in spirit.

@gvalkov
Copy link
Contributor Author

gvalkov commented Jan 31, 2016

Hi @Ivoz. No problem at all - I'm happy to see pip keep getting better and better!

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 3, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants