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

Use `python -m fabric` rather than `fab` in tests. #1590

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@BenSturmfels

BenSturmfels commented Apr 18, 2017

The test_abort_message_only_printed_once test needs Fabric already installed to run, since the fab executable is created only during install. This wouldn't ordinarily be a problem, but when packaging Fabric for a system like GNU Guix, we'd like to be able to run the tests before installing.

This change switches this single use of fab to the equivalent python -m fabric.

@BenSturmfels

This comment has been minimized.

BenSturmfels commented Apr 18, 2017

Thanks also for a brilliant tool which I use nearly every day for work! :)

@bitprophet

This comment has been minimized.

Member

bitprophet commented Apr 19, 2017

I'm sure I'm missing something silly but how are you able to use -m fabric (implying fabric is on sys.path and thus at least partially installed) yet not fab (implying setup.py install has not been run or entrypoints are otherwise being skipped)?

That said I have no actual problem with this, just want to understand the background more. Thanks!

@bitprophet bitprophet added this to the 1.10.6 milestone Apr 19, 2017

@BenSturmfels

This comment has been minimized.

BenSturmfels commented Apr 20, 2017

The -m fabric works because the current directory is added to sys.path, and the top level of the source tree where the tests are run from contains the module fabric (a directory called "fabric" that contains an "init.py). It sounds like you're overthinking it, but let me know if I'm missing something silly myself.

@BenSturmfels

This comment has been minimized.

BenSturmfels commented Apr 20, 2017

Sorry just realised that I didn't understand this as well as I thought - it's because it has an __init__.py and a __main__.py that it can be run with -m fabric.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Apr 20, 2017

Ah, gotcha - forgot about the CWD-on-path angle, that makes sense now. Thanks!

@bitprophet

This comment has been minimized.

Member

bitprophet commented Apr 24, 2017

Realized I never asked how exactly you run the tests pre-install...while I don't use it often I suspected perhaps it was via python setup.py test (which appears to install test deps, and run egg_info and build_ext for Fabric itself, but not any actual installation).

Ran that in an env w/ Fabric uninstalled, and yup, I get a kaboom on the test(s) using the helper being patched.

Cherry-picked the patch and...hm, still doesn't work, I now get fabric is a package and cannot be directly executed; confirmed I get this by hand too with e.g. python -m fabric -l. Ah - this seems to be a Python 2.6 (my default dev version) vs 2.7 issue, works fine under 2.7. Cool.

EDIT: well, not cool, insofar as this means tests will break under 2.6. Grump. Gotta think about that for a sec.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Apr 24, 2017

Cool, looks like we can simply explicitly request fabric.__main__ and that works on both interpreter versions. Crisis averted 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment