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

using from within in a Python 2 virtual environment? #585

Closed
indirectlylit opened this issue Oct 23, 2018 · 14 comments
Closed

using from within in a Python 2 virtual environment? #585

indirectlylit opened this issue Oct 23, 2018 · 14 comments

Comments

@indirectlylit
Copy link

We'd love to use black in our project, but the Python 3 requirement makes this difficult because our application needs to be able to be developed and run under both 2 and 3.

Any tips for integrating black into a version-agnostic development environment?

@jgirardet
Copy link
Contributor

you only need black to be installed in your computer, not in the venv.
black will format python2 code.
You can also a run a blackd instance on one server and format your files via http.

@JelleZijlstra
Copy link
Collaborator

As @jgirardet says, Black formats Python 2 code correctly already. We're unlikely to make it possible to run Black under a lower Python version, but that's not necessary to use the tool.

@indirectlylit
Copy link
Author

Thanks for the info! Yeah I'm aware that it formats py2 code fine which is why we want to use it.

I'd like to avoid requiring our developers to sudo pip3 install black: there are many possible ways people install Python, so asking people to install global packages seems like risky advice to support. Currently it's easier for us to say "if things are broken, make a new virtual environment".

If black had some system-level installers to hide the details (e.g. through apt, brew, and a windows installer) that would be easier for us to incorporate into our developer setup guide.

Similarly, running a blackd instance is an interesting idea if we had a foolproof way of recommending devs install it on their local machines.

@rooterkyberian
Copy link

you can also run it in Docker: https://github.com/jbbarth/docker-black

@asottile
Copy link
Contributor

asottile commented Nov 2, 2018

sudo pip / sudo pip3 should really not be used -- if you must use pip install --user. I personally don't like usersitedir so I set up a virtualenv in my homedirectory as follows:

virtualenv ~/opt/venv
~/opt/venv/bin/pip install black
ln -sf ~/opt/venv/bin/black ~/bin/black

and then I put ~/bin on my PATH

@cas--
Copy link
Contributor

cas-- commented Nov 5, 2018

Surprised that no one has mentioned that pre-commit creates a Py3.6 venv just for black.

Black docs: https://github.com/ambv/black#version-control-integration

From our pre-commit config:

repos:
  - repo: https://github.com/ambv/black
    rev: 18.9b0
    hooks:
      - id: black
        name: Fmt Black
        language_version: python3.6

Run from terminal with:

pre-commit run --all-files
pre-commit run --files test.py

@indirectlylit
Copy link
Author

that looks like the correct answer - closing :)

@vikas1018
Copy link

@JelleZijlstra: Do we need to specify language version as language_version: python2.7 in pre-commit-config.yaml to format python2.7 codebase?

@cas--
Copy link
Contributor

cas-- commented Nov 22, 2018

@vikas1018 Black requires no configuration to format Py2.7 code.

The language_version option is to tell pre-commit to run Black under Python 3.6 interpreter.

@indirectlylit
Copy link
Author

Just to follow-up: while the pre-commit integration is potentially useful, the fact that Black requires >= python 3.6 makes it much less useful. Our developers run a variety of versions of Python 3. For example, the latest brew installs 3.7 and Ubuntu has 3.5.

Therefore we've been exploring distributing self-contained binaries built using PyInstaller as described in #362

It's a lot of hoops to jump through, but the benefits seem worth it. Would love to see Black either support all versions of Python 3 or have official self-contained installers for major operating systems in the future to support the diversity of developer and CI environments.

@indirectlylit
Copy link
Author

looks from #521 like py 3.5 support will not be happening

@asottile
Copy link
Contributor

For ubuntu xenial if you're willing to use a ppa: deadsnakes (PPA page) provides backports of 3.6 / 3.7 / 3.8

with pypy3.6 available I assume it'll work pretty soon -- some cursory tests shows it breaks for this

this patch makes black work with pypy3.6 though:

$ diff -u /tmp/t/pypy3.6-v7.1.0-linux64/site-packages/black.py{.old,}
--- /tmp/t/pypy3.6-v7.1.0-linux64/site-packages/black.py.old	2019-03-31 12:35:22.813881755 -0700
+++ /tmp/t/pypy3.6-v7.1.0-linux64/site-packages/black.py	2019-03-31 12:34:40.597881755 -0700
@@ -3721,7 +3721,7 @@
         new_cache = {**cache, **{src.resolve(): get_cache_info(src) for src in sources}}
         with tempfile.NamedTemporaryFile(dir=str(cache_file.parent), delete=False) as f:
             pickle.dump(new_cache, f, protocol=pickle.HIGHEST_PROTOCOL)
-        os.replace(f.name, cache_file)
+        os.replace(f.name, str(cache_file))
     except OSError:
         pass
 

@jcopps
Copy link

jcopps commented Feb 1, 2021

you can also run it in Docker: https://github.com/jbbarth/docker-black

Love this. Very helpful and handy.

@ichard26
Copy link
Collaborator

ichard26 commented Feb 5, 2021

If compatibility isn't an issue, the upcoming black updates (can't give you a timeframe) should have OS native binaries available through GitHub Releases (again, our original config broke after 19.10b0) . ex. the black file in this release: https://github.com/psf/black/releases/tag/19.10b0 (although this version is quite old!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants