Comments (11)
@pfmoore having the sampleproject try to cover all best practices is feeling overwhelming at the moment. I only feel comfortable trying to maintain this for packaging best practices. I'll wait for your response, but I'm inclined to close the non-packaging issues, and maybe remove the tests directory all together, so it's clear we're not even trying to offer guidance there.
from sampleproject.
@qwcode Given that nobody seems able/willing to give good recommendations about wider project practices (something I found out when this was a personal project from questions I asked on PyPA and distutils-sig) I have to agree.
Whether that leaves enough meat to make this project worthwhile as a reference (as opposed to simply documenting the recommendations in the PUG) I'm not sure.
I'm -1 on actually removing the tests directory, as that makes the project largely useless for the purpose I originally intended it, i.e. as a starting point.
from sampleproject.
@pfmoore for example, see PR #5 . It's advocating nose, and very heavy use of pylint. I don't think PyPA should get into that.
I do see PyPA advocating whether to include tests in the sdist or have them installed. So, for that reason, having tests in the sample makes senses, so I won't remove them
Apologies, if it feels like Pypa (or me) took your project, and changed the scope. Think of it as a contribution, vs a loss : )
If you want, we can change the name to "sample_packaging_project", so you could continue on with your broader effort back in your personal github workspace. let me know.
Even with the reduced scope, I do still think it's worthwhile to keep, and the PUG is currently linking to it multiple times.
from sampleproject.
@qwcode no, it's not a problem. I think the reality is that there isn't a "Python project best practice" at this point, so there is bound to be debate. But I do think this should remain usabe as a "copy this and start developing" template, so I'm happy that the tests directory remains - there should be a reminder that people should be writing tests, even if we can't offer any advice on how.
On that note, maybe we need a "docs" directory as well?
from sampleproject.
@pfmoore you can add docs if you want, but I won't personally partake in any PRs where people quibble about sphinx practices. my interest in the docs directory would be how it relates to packaging, e.g. how to make sure your docs are installed, if that's important for some reason.
from sampleproject.
About the PR #5, I have to precise that my idea was to propose only the two first commit as a pull request. As I lack experience with Github, I had not anticipated that the remainder would be integrated into the PR.
I fully understand that not anyone is so Pylint-maniac as I am, and that this is not the place for my personal recipes.
Though, I think it's important that the 'python setup.py install' works in a fresh virtualenv, especially for saving time of beginners, for whom small corrections of syntax and imports can be painful.
Optionally, always thinking beginners, I think it's logic to have a basic class and a basic test in a sample project (but without requiring nose). Something saying like «Welcome to python, you will write classes and tests, and this is good».
If you agree with this principles, I can make a new pull request corresponding to this requirements.
from sampleproject.
@qwcode OK, if there's Sphinx controversy, you're right, let's not get into that. Leave docs for peoplr to add themselves...
from sampleproject.
I would actually find a slightly more complex example of how tests should be structured to be useful (eg more than one test file).
I used the sampleproject as the base for my project, then read instructions in unittest and nose that all of my tests should "importable" for test discovery. I came back to sampleproject to see how that'd been accomplished with the tests in a separate directory from the other code, but it didn't demonstrate this.
I understand the desire to be framework-agnostic, but it'd be nice to have some demonstration of a scaleable way to write tests using one of the popular frameworks (whether it's unittest, nose, py.test). I don't know if all unittest/nose projects structure things differently to sampleproject so tests can be imported as, eg myproject.tests
, or if they just use one of the special entry-point scripts which manipulate the PYTHONPATH
, and I'd find it useful if some sample project existed which showed a "recommended" setup.
from sampleproject.
@ncraike I don't think there is any common approach, unfortunately. With py.test
(which is what I prefer these days) you don't even want the tests to be importable (and I think making them so is problematic).
So there really isn't anything we can do beyond having a tests
directory before we get into making framework recommendations :-( (Actually, even having a tests
directory is a decision - many projects seem to include tests within the distributed package itself).
from sampleproject.
(Thanks for the quick reply.)
Ah, right. Yeah, I was trying to get a sense of what is done outside of the couple of really big, old projects I've worked on. Even knowing that there isn't an agreed upon standard is valuable.
I can certainly understand the argument for not installing your test code along with the code your project needs to actually do its job. I've also seen others advocate keeping your unit tests right next to the code they test, with the argument that everyone knows where they are, then.
Well, I guess I'll just pick something, and not so feel bad that it isn't "best practice".
from sampleproject.
I know that feeling completely :-) These days, I tend to use py.test and just base what I do on pip's setup (which is very complex, but the basics are straightforward enough) just because it's what I'm most familiar with. I suspect that's a common approach.
BTW, I'm going to close this issue, as we're not likely to do anything with it, so no point in it just sitting here.
from sampleproject.
Related Issues (20)
- packet queue is empty, aborting HOT 2
- How do you test this? HOT 2
- Tools
- How to include non python configuration files HOT 1
- How to control spelling incorrection even if phonetically sound same HOT 1
- pyproject.toml: references a "python_requires" key that does not exist HOT 2
- help! Executing file is not working HOT 2
- sampleproject doesn't include files `setup.py` and `setup.cfg` (and maybe other) one of the latest published guides claims it should have HOT 1
- Unclear description of "readme" field in pyproject.toml HOT 2
- The package name HOT 3
- TypeError: unhashable type: 'dict' HOT 4
- Should development dependencies be included in the optional section?
- Error in documentation regarding Packaging and Distributing projects using Setuptools
- Stop advertising adding `wheel` as an unconditional PEP 517 build dependency HOT 6
- Should PyPUG editors have access to this project? HOT 3
- Remove Python version 3.7 to unblock tests HOT 1
- Update tox version? And tox best practices? HOT 2
- Sample build breaks if LICENSE.txt file contains GPL2 license text (containing 0x0c) HOT 13
- Flake8 configuration should not use select
- pyproject.toml file don't mention anything about the compatible platforms allowed by Wheel?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sampleproject.