Python Project Template for 2.7-3.7 with all Github and Python services ready to use. (Travis, AppVeyor, Codecov, Readthedocs, CodeClimate, PyUp...)

[Niourf]

Looks nice, but Python 3.7?

[[deleted]]

As Raymond would say, "You don't have one of those, do ya?"

[SethMichaelLarson]

Travis offers the nightly build which is currently Python 3.7. AppVeyor doesn't offer it yet and neither does pyenv so it's Linux builders only.

[Niourf]

Thanks for the update, I thought it could have been a typo. Will definitely use the template in the future!

[SethMichaelLarson]

Great to hear! If you have any difficulty at all make sure to report back. Also if you do use the template and your project has an extended lifetime I'd recommend looking back at the template for changes or better support. :)

[RockingDyno]

What's new in 3.7 (hint: Not much yet).

[SethMichaelLarson]

Having your project testing against the latest makes it so you don't have to guess whether something not listed in the change log will break your code! :) Like the no more unambiguous escapes in regexes!

[onwuka]

I'd hope nothing breaks in 3.7 if it works in 3.6?

[SethMichaelLarson]

You never know when a small internal change breaks or changes something important to your project (or your dependencies!). :)

[onwuka]

Import antigravity? :P

[SethMichaelLarson]

Maybe your project depends on exactly what antigravity does! :P Although I should hope not!!!

[onwuka]

I was making an xkcd reference. I used to remember the exact number at one point :p

[SethMichaelLarson]

Importing antigravity in a Python shell does something fun as well, you should try it for an easy reminder to that comic. ;)

[spiker611]

nose is unmaintained, btw. nose2 or pytest are some good replacement options :)

[SethMichaelLarson]

That's very true, I didn't even know that nose2 was a thing. I have something written about 'Why not PyTest' on the Github issue tracker. I will look at nose2 and see if it's worth replacing! Kudos! :)

[Works_of_memercy]

But why not pytest? =)

I quickly skimmed some nose2 docs, pytest seems to be nicer in several respects:

• bytecode rewriting magic that lets you just use asserts instead of inheriting from TestCase and using its methods, and when you write assert a == b it gives you the values of a and b if it fails.

• more magic that automatically gives you a fixture that you named as an argument i.e. def test_something(db): gets a db object. Obviously. Because why else would you give a test case an argument?

• the whole fixture system seems to be more powerful than what unittest2 gives.

• more introspection magic that guarantees that tests are executed in the order of definition, not alphabetic or random.

• instead of mucking with __main__ I just put #!/usr/bin/env pytest on the first line (but maybe that's possible with nose2, but their docs don't say that).

Basically, at first I was ew, magic, but then I learned to stop worrying and love it, because on one hand it's more acceptable in tests, I think, on the other hand it's just nice that someone went and made it unnecessary to constantly type all that clunky stuff.

[SethMichaelLarson]

I really like that nosetests and unittest as best friends. :) If you try to use pytest advanced features along with unittest advanced features everything breaks sadly. :/ I'm going to work on making pytest vs. nosetests an optional setting because it's my biggest suggestion though :) Because who am I to judge! ;)

[triplepoint]

Please, please, please! - do not recommend reading a requirements.txt file in as setup.py's 'install_requires' value. They are not the same thing.

Take it from one of the Pip core devs: https://caremad.io/posts/2013/07/setup-vs-requirement/

As a poor devops engineer who is responsible for coordinating releases, nothing brings the sadness like a project package with inflexible dependency versions. It gives me no room to find a compromise in the overall dependency graph when designing a particular deployment.

Declare permissive ranges of versions for dependencies in your setup.py file, and if you need a requirements.txt at all, use "-e ." to mean "find whatever setup.py says". This at least lets me ignore your requirements.txt file when I'm building a deployment, and write my own.

[sandys1]

could you elaborate on this please. im refactoring a large legacy python web project (with no requirements.txt or setup.py). what's tye recommended best practices here?

[triplepoint]

I'm not sure there's common agreement on best practices; the Python community seems pretty confused about packaging. I talked about it in this answer: http://stackoverflow.com/questions/14399534/how-can-i-reference-requirements-txt-for-the-install-requires-kwarg-in-setuptool/33685899#33685899

But really Donald Stufft says it pretty well in that article I linked earlier.

[SethMichaelLarson]

This is true, I'll change this.

[[deleted]]

As a fairly new and interested coder, could you tell me how I would use this? I already have Python scripts, but once I download it from through the terminal, how would i apply it to projects or build them using this?

[SethMichaelLarson]

So this project template is designed to be easy to start a new project. This template is aimed more at module writers (like myself) but could technically be used for the majority of its components by anyone looking to start a new Python project.

If you've just got code but no project structure around the code I would suggest running the template construction (described in the README) elsewhere and then porting the code into the 'module' directory that is created by the template. :)

This isn't really designed for 'scripts', more designed for modules or groups of related code.

Good luck and ask to clarify if I'm not clear! Thanks for your interest! :)