Skip to content

Fix user_site failures on pypy #616

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
pnasrat opened this issue Jul 29, 2012 · 9 comments
Closed

Fix user_site failures on pypy #616

pnasrat opened this issue Jul 29, 2012 · 9 comments
Labels
auto-locked Outdated issues that have been locked by automation

Comments

@pnasrat
Copy link
Contributor

pnasrat commented Jul 29, 2012

Added pypy travis support - lots of tests in test_user_site failing

http://travis-ci.org/#!/pypa/pip/jobs/1982085

@qwcode I'm looking at today but feel free to chip in.

@pnasrat
Copy link
Contributor Author

pnasrat commented Jul 29, 2012

pypy/lib-python/2.7/no-global-site-packages.txt 

We use path_locations to figure out and set the attribute env.lib_dir - but virtualenv uses lib_dir = home_dir but puts no-global-site-packages.txt in site_packages_filename = join(site_dir, 'no-global-site-packages.txt')

@qwcode
Copy link
Contributor

qwcode commented Jul 29, 2012

beginning to look now...

@qwcode
Copy link
Contributor

qwcode commented Jul 29, 2012

yes, we need to change test_pip to use the same location as virtualenv.

when I built the new virtualenv_no_global() function, I was very careful to mirror how virtualenv was locating the no-global file.

#this mirrors the logic in virtualenv.py for locating the no-global-site-packages.txt file site_mod_dir = os.path.dirname(os.path.abspath(site.__file__)) no_global_file = os.path.join(site_mod_dir,'no-global-site-packages.txt')

but in test_pip.py, I had just blindly reused this line, (env.lib_path/'no-global-site-packages.txt').rm(), that I had found in a pre-existing user test. I'll fix in a pull. need to get pypy set up locally.

@qwcode
Copy link
Contributor

qwcode commented Jul 30, 2012

so I locally fixed the no-global file location issue, but it's opening up other issues with pypy apparently not supporting --user installs. I'm still analyzing....

prior to me updating the --user tests, some of the old tests were skipping for pypy like so:

    # FIXME distutils --user option seems to be broken in pypy
    if hasattr(sys, "pypy_version_info"):
        raise SkipTest()

I didn't carry that over into my tests. skipping may end up being the answer, but let me confirm exactly what is wrong with pypi and --user installs, and report back.

I couldn't find any open bugs about --user on pypy's bug tracker
https://bugs.pypy.org/

@qwcode
Copy link
Contributor

qwcode commented Jul 30, 2012

I tried a --user install using a minimal distutils package pypy setup.py install --user and encountered a bug.
I might do a pull request to pypy later to fix this, but for now will add a skip for any --user tests under pypy.

pull coming later, after I try to sort out the the other pypy failures.

pnasrat added a commit that referenced this issue Jul 30, 2012
pypy test fixes for issue #616 and #617
@pnasrat
Copy link
Contributor Author

pnasrat commented Jul 30, 2012

Great - lets ensure we have a bug filed for fixing --user in pypy

@pnasrat pnasrat closed this as completed Jul 30, 2012
@pnasrat pnasrat reopened this Jul 30, 2012
@pnasrat
Copy link
Contributor Author

pnasrat commented Jul 30, 2012

Actually just keep this bug for that.

@qwcode
Copy link
Contributor

qwcode commented Aug 4, 2012

hey @pnasrat , if you don't mind, created a specific "workaround" bug for the disabling of the --user tests for pypy.
going to create a few other workaround bugs to track the other workarounds that I'm finding in the code.

@qwcode qwcode closed this as completed Aug 4, 2012
@pradyunsg pradyunsg removed !release blocker Hold a release until this is resolved labels Feb 8, 2019
@lock
Copy link

lock bot commented May 29, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label May 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators May 29, 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

No branches or pull requests

3 participants