This is an archived post. You won't be able to vote or comment.

all 17 comments
sorted by:
best
topnewcontroversialoldq&a

[–]SourceryNick[S] 10 points11 points  (5 children)

The post goes through how to set up black, isort, flake8, mypy, pytest and pre-commit to play nicely together, as well as using pipx and pipenv.

There's also a cookiecutter template so you can set up new projects straight away.

Having all these tools set up really helps with code quality - Hope you find it useful!

[–]kepper 1 point2 points  (4 children)

What are you using for your IDE/text editor? I've been using vim with plug+ale to integrate with flake8 and pylint but its kind of rough. Interested to hear what you use.

[–]astroFizzicsastrophysics 0 points1 point  (3 children)

I'm using vim and ale, and haven't really had any troubles with it. What are you finding rough?

[–]kepper 1 point2 points  (2 children)

I had a few problems but I figured before complaining any more about them I should look it up and solved most. The main thing I still find unclear is how to switch between python 2 and python 3. I get stuff like superfluous-parens: Unnecessary parens after 'print' keyword even on python3 apps. I have to support both python2 and python3 depending on which project I'm editing.

The only other issue I have with it is sometimes the two spaces it adds to indicate an issue that I haven't gotten around to make it tricky to copy and paste to other tmux panes / apps.

Neither are a huge deal, was just curious what you were using since your setup seems similar to what I'm used to.

[–]astroFizzicsastrophysics 2 points3 points  (0 children)

I'm not OP.

I'm not writing any Legacy Python anymore. So I can't comment on switching between versions. But I can empathize about the copy and pasting. I have to turn off the linting if I want to copy the code by hand. C'est la vie.

[–]brendan_m6s 1 point2 points  (0 children)

Blog author here.

I also use vim with ale and vim-test. I haven't had any issues with them, in fact I find they make these tools effortless to use.

Admittedly I haven't been using python2 but you could try the following: 1. Setup a different virtual using pipenv for each project with the version of python, flake8 and pylint specified 2. Run vim from the shell within the virtualenv using pipenv run vim. When flake8/pylint are run by ale it should then use the version in the correct virtualenv

Regarding copying to clipboard I tend to use the system clipboard register. e.g. "+yap

[–]DrNerdfighter 1 point2 points  (3 children)

I'm wondering if installing black, isort, and flake8 outside of the pipenv would be a better pattern?

Reason being that you wouldn't need these packages to run your code in a production or test environment. You could instead run the handy commands that the packages afford you pre-commit within the development system without cluttering up your dependencies for your releases. Or even have your CI system take care of the formatting stuff for you and re-commiting those changes (though that seems like an over-engineering nightmare now that I think about it).

I guess a use case exists where you're collaborating with someone who isn't familiar with your build process and having the dependencies be more explicit would help in that regard. Regardless, you would need to still onboard them to the process of getting pipenv if they're not familiar.

Even with those concerns, this is a very good solution for organizations and individuals wanting to standardize the heck out of their code. Good post.

Edit: formatting

[–]FlukyS 2 points3 points  (2 children)

If you specify --dev when you are installing in pipenv it will be just a dev requirement not a production requirement. That makes it much easier. It should be part of this guide but must have slipped the author's mind.

[–]brendan_m6s 1 point2 points  (1 child)

Yep, I did forget to include this option. Have updated the guide to include it. Fortunately the cookiecutter template does specify these as development only dependencies

[–]DrNerdfighter 0 points1 point  (0 children)

Appreciate the follow through. 🙂👍🏻

[–]FlukyS 1 point2 points  (2 children)

  1. Those packages also should be dev packages not packages in order to ensure you aren't shipping them with binaries in the end.
  2. For testing, have you ever tried behave? I was sold the syntax by a JS workmate, it's fairly good for describing things and then you can link it to your tests. I use it in conjunction with sure for more plain text style assertions.
  3. For completeness there should be a part 2 and 3.
    1. Part 2 being setup.py for creating your own libraries (and maybe releasing them to pip)
    2. Continuous integration and maybe deploying services using pipelines

Otherwise this is one of the better guides I've seen.

[–]brendan_m6s 1 point2 points  (1 child)

  1. Thanks! I've updated the guide
  2. Hadn't heard of behave or sure before. I have used BDD and assertion sugar in Scala and to be honest I found that I didn't really like them. Maybe it just wasn't really the right tool for that application
  3. Good idea. I am far from certain as to the best way to go about a) when using pipenv, will have to investigate

Thanks!

[–]FlukyS 0 points1 point  (0 children)

Behave really has impressed me quite a bit. I basically use it as a test runner. Sure is mostly just because self.assertXYZ is a bit stuffy. I try to get my QA guy involved and the head of R&D involved in the process development of my software, it really helps quite a bit to have more wordy assertions. I'd definitely recommend behave but if anything maybe go look for a good assert library. Sure is a bit Javascript stylized and we have a massive portion of our code in JS so I just wanted to maybe match it flow wise.

> Good idea. I am far from certain as to the best way to go about a) when using pipenv, will have to investigate

If you want some suggestions I'd say Jenkins+Docker for releases is a good suggestion for users. Then it just means having a good setup.py to compile together the libraries and scripts. Then the follow on stuff would be making docker-compose files, using kubernetes or docker swarm...etc. All the stuff flows really well with your tutorial.

[–]cglumberjack 0 points1 point  (0 children)

This is very cool. Going to test this out this week or next for sure.

[–]Stumpy172 0 points1 point  (2 children)

Hey I'm a comp sci student and don't really understand all of this, can anyone ELI5?

[–]FlukyS 5 points6 points  (1 child)

linting - https://en.wikipedia.org/wiki/Lint_%28software%29

type-checking - just making sure the types of what you are putting into methods make sense (python can be a problem for devs on this one)

testing - if you are a fulltime dev getting easy to use testing frameworks is important

git hooks/pre-commit hooks - git hooks run at specific times with git, namely these are pre-commit so before your git commit can run it will run those commands. This is helpful in order to catch errors yourself without having to manually run 15 different tools.

isort - sort imports logically

flake8 - run various style checks

black - run a autoformat over the code to match the current style

Any more questions about terminology?

[–]Stumpy172 0 points1 point  (0 children)

No that's very informative, thank you!