-
Notifications
You must be signed in to change notification settings - Fork 59
Enh: Add tests pages - run tests in ci and locally to guide #145
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
Conversation
- name: Install dependencies | ||
run: | | ||
python -m pip install --upgrade pip | ||
python -m pip install nox |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With a cache, this install should probably also be an --upgrade
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok that makes a lot of sense. @ucodery i asked this question in slack since it came up in the review as well. the caching part of this workflow is really complex. i think for a beginner it will be overwhelming. i'm curious what people think about how much efficiency caching really adds especially for someone new to packaging. what are your thoughts on that?
even if it adds considerable benefit it feels like cognitive overload to me in a beginner friendly tutorial but might be good in a more advanced tutorial (ie series part 2?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok we have collectively decided to remove the caching part in this ppage just to keep things simple.
i opened an issue to capture this here and we can revisit it once the core pieces of the guidebook are all pulled together.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some smaller comments.
Was there a larger discussion on discourse around promoting nox? I didn't see anything on Slack. It's, of course, a fine choice and I'm very late to the party, but I'm personally against nox for the simple reason that I need to write Python code that I may introduce bugs in rather than simply configuring the tool as I would for tox, for example.
tests/tests-ci.md
Outdated
steps: | ||
- uses: actions/checkout@v4 | ||
with: | ||
# fetch more than the last single commit to help scm generate proper version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is never mentioned what scm
is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also 20 seems like a magic number to me. I personally never had an issue as long as the depth is >1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is totally random and magic and will vary based upon people's commit and release cadence.
but here is what i'm thinking about now based on your comments here and below.
this action is REALLY COMPLEX with the cache and fetch depth pieces. AND we will cover fetch depth when we cover SCM based release / versioning - not here. so what if we remove both caching (and add it as an admonition perhaps??) And the SCM fetch depth stuff so we can focus ONLY on running tests here. that is what my gut is telling me would be most beginner friendly. so i'll go ahead and do it and we can always add. the other stuff back OR have an example in our package repo with the more complex example of the action that supports scm (and maybe caching??)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I completely agree. I think, this guide would benefit a lot from ignoring all the caching part and just focusing on running the tests part.
tests/tests-ci.md
Outdated
uses: actions/setup-python@v4 | ||
with: | ||
python-version: ${{ matrix.python-version }} | ||
cache: pip # By adding cache here, you are telling actions to reuse installed dependencies rather than re-downloading and installing them each time. This speeds up your workflow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm somewhat doubtful about caching. All files that you cache still have to be transferred from GH's storage to the worker machine. That is faster than fetching from a random internet source, but still is a network request. Secondly, I actually like to not cache because then I get the latest versions installed with every run. That way I can discover new versions of dependencies that somehow break my package faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok - from my perspective the issue of caching on this page is beyond the scope of this page. so i wrote this above - i'm leaning towards removing it altogether just to keep the example simple. we could have another page on more complex test builds too!
@namurphy does that seem reasonable to you for this page? to just start simpler because most of our users will be on the newer end of packaging?
we could then have a page devoted to more efficient CI workflows or add sections to these pages with those more complex concepts covered. The code in this action is a bit tricky to follow and explain. And i don't know enough in terms of how much efficiency it does or does not provide. i'll post in slack as well in case folks want to discuss.
tests/tests-ci.md
Outdated
# You only need to upload code coverage once to codecov | ||
- name: Upload coverage to Codecov | ||
if: ${{ matrix.os == 'ubuntu-latest' && matrix.python-version == '3.10'}} | ||
uses: codecov/codecov-action@v3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, if my code contains platform- or Python version-specific logical branches, I exactly want to upload coverage multiple times so that all branches are covered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i hear you! this guide is really focused on pure python builds and this tutorial needs to be beginner friendly! I think those newer to packaging likely need a simple point of entry BUT it's important to point out more complexity could be on the horizon! so i just edited the comment to say You only need to upload once unless you have a more complex build.
Fix: review edits from Jonny p2
Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/ci.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/ci.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/ci.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/ci.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/ci.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu>
Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu>
Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu> Update ci-tests-data/run-tests.md Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu>
Co-authored-by: Trevor James Smith <10819524+Zeitsperre@users.noreply.github.com> Fix: edit from trevor Co-authored-by: Trevor James Smith <10819524+Zeitsperre@users.noreply.github.com> Fix: edit from trevor Co-authored-by: Trevor James Smith <10819524+Zeitsperre@users.noreply.github.com> Fix: edits from Trevor Co-authored-by: Trevor James Smith <10819524+Zeitsperre@users.noreply.github.com>
Co-authored-by: Nick Murphy <namurphy@cfa.harvard.edu>
Co-authored-by: Trevor James Smith <10819524+Zeitsperre@users.noreply.github.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com> Update ci-tests-data/ci.md Co-authored-by: Carol Willing <carolcode@willingconsulting.com> Update ci-tests-data/ci.md Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Fix: navigation
Co-authored-by: Jeremy Paige <ucodery@gmail.com> Co-authored-by: Moritz E. Beber <midnighter@posteo.net>
Co-authored-by: Moritz E. Beber <midnighter@posteo.net>
Gosh @Midnighter that's a really good question. i think we talked about nox very early on but i'd have to dig into that discussion to find it. Essentially what is nice about nox is the configuration is python based so it's less cognitive overload vs learning tox. i definitely found it to be a lot more user friendly. so we did decide to recommend nox but that doesn't mean people might prefer to use tox (or other tools for that matter). some still use makefiles! a few benefits:
i think those are the big takeaways. I was able to get up and running with nox super fast (i moved from make) and it's also been great to run things like mypy across python versions and such (my personal take from our maintainer experience!). it just has been a huge time saver in my experience. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
conf.py
Outdated
@@ -133,7 +133,7 @@ | |||
|
|||
|
|||
# Social cards | |||
ogp_site_url = "http://www.pyopensci.org/python-package-guide" | |||
ogp_site_url = "http://www.pyopensci.org/python-package-guide/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lwasser Maybe use https
set up virtual environments, and run tests across Python versions using the environment manager of your choice with a | ||
single command. | ||
|
||
:::{note} Nox Installations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about something to notify the reader that nox
doesn't need to be installed for the target python versions in order to manage them (as opposed to the venv
, which must be present for each python version under test)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point. i'm not sure if a beginner would get confused with that additional information or whether it would be useful. i hadn't thought about that before because nox just always worked! if you have suggestions for how to word it in a way that it doesn't make the user more confused i'm open to that!
tests/run-tests.md
Outdated
""" | ||
|
||
# Install dev requirements | ||
session.install(".[tests]") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to nox
, session.install
will always run pip
. For conda it is recommended to use session.conda_install
(there isn't a mamba_install
, I assume conda_install
works for both). I'm not sure what the best practice for installing a package under test in a conda environment is, but at least the package's dependencies should be installed via conda_install
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed! i missed the conda_install method in the docs!
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
Co-authored-by: Jeremy Paige <ucodery@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com> Co-authored-by: Jeremy Paige <ucodery@gmail.com>
Co-authored-by: Alex Batisse <alexandre.batisse@hey.com>
ok everyone! i've fixed / responded to all suggested changes and this is now ready to merge!! it should be live in the next 5-10 minutes! 🚀 |
i'm also confused as to why htmlproofer is passing given we have new pages here but we shall see! |
This is ROUND 2 of the community review of the tests pr that we started back in september
see pr #104 for reference.
This has the next two pages in that section in a edited format from the first review
Reviews are welcome on this pr! Given this is a meatier PR, let's try to get reviews in by 15 January 2024 with the goal of merging the following week. i'll try to chip away at feedback as it comes in to stay on top of things!