-
Notifications
You must be signed in to change notification settings - Fork 660
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
Add eachdist.py to simplify build. #291
Add eachdist.py to simplify build. #291
Conversation
Excluding `build` for black isn't a great idea when travis is checking out under `/home/travis/build/open-telemetry`.
bf28f53
to
e62f5bc
Compare
Codecov Report
@@ Coverage Diff @@
## master #291 +/- ##
==========================================
+ Coverage 85.74% 85.88% +0.14%
==========================================
Files 33 33
Lines 1613 1630 +17
Branches 181 182 +1
==========================================
+ Hits 1383 1400 +17
Misses 182 182
Partials 48 48
Continue to review full report at Codecov.
|
First, black already parsers .gitignore, so no need for the exclude option in pyproject.toml (apart from checked in generated files). The problem with this is that .gitignore has `build/` in it already and black does not take into account the root of the git repository, but instead seems to apply the ignore patterns to the path that results from the command line arguments (be that relative or absolute).
4d93900
to
2524efe
Compare
Fixed in ea07bd6 |
f3900b3
to
83120d6
Compare
@@ -3,21 +3,7 @@ line-length = 79 | |||
exclude = ''' | |||
( | |||
/( |
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.
If I understand correctly, this file is for excluding certain folders from being checked with black
. We are removing these because the tox
will run the eachdist.py
script (which will only run on folders specified in eachdist.ini
), instead of running black
directly correct? For cases when I want to fix the lint directly myself without running tox
, will changing this file effect that?
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.
No, running black directly vs eachdist.py makes no difference at all. This was removed because black already checks .gitignore and so the lines were just redundant. This is actually a change independent from the rest of this PR and could be merged separately.
@@ -0,0 +1,10 @@ | |||
pylint~=2.3 |
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.
Should this file have the word constraints
in it as well? dev-constraints.txt
maybe? Due to use using it as constraints in tox
.
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.
Well, if you use the install --with-dev-deps
or develop
commands, it will be used as a requirements file.
-c dev-requirements.txt | ||
sphinx | ||
sphinx-rtd-theme | ||
sphinx-autodoc-typehints | ||
opentracing~=2.2.0 | ||
Deprecated>=1.2.6 |
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.
How come no -c dev-requirements.txt
for testenv:py37-tracecontext
?
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 seems that environment doesn't use any requirement that is listed in dev-requirements. Also, because the dev-requirements file is used for installing too (#291 (comment)), I didn't want to include all that.
This project uses [`tox`](https://tox.readthedocs.io) to automate some aspects | ||
To quickly get up and running, you can use the `scripts/eachdist.py` tool that | ||
ships with this project. First create a virtualenv and activate it. | ||
Then run `python scripts/eachdist.py develop` to install all required packages |
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.
What's the difference between python scripts/eachdist.py develop
and python scripts/eachdist.py install --editable
?
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 an alias for install --editable --with-dev-deps --eager-upgrades
(see
opentelemetry-python/scripts/eachdist.py
Line 82 in cf7e685
editable=True, with_dev_deps=True, eager_upgrades=True |
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.
This is awesome, it makes writing code so much easier!
Just a non-blocking suggestion and it would be nice to have an example of how to use exec
, I ended up digging through the test file to figure out what format
was expecting.
This was actually bugging me too, so I took the time and documented
You're welcome! |
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.
This is a huge improvement, and will make developing with multiple packages in the same repo much easier. I'm taking some of the script on faith here, and didn't do an exhaustive review, but it did work as advertised when I tested it.
pylint | ||
flake8 | ||
isort | ||
black |
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.
These are listed in dev-requirements, why duplicate them here?
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.
Because dev-requirements has more requirements than each tox environment on its own. That's why it's used with -c
so that only the version requirements are taken, but the targets are not automatically installed. I only moved the versions out of the toxfile with this. If I used -r
, it would install unnecessary packages for each target (e.g. we don't need pytest or sphinx for the lint toxenv).
sphinx | ||
sphinx-rtd-theme | ||
sphinx-autodoc-typehints |
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.
Same question
sphinx-rtd-theme~=0.4 | ||
sphinx-autodoc-typehints~=1.10.2 | ||
pytest!=5.2.3 | ||
pytest-cov>=2.8 |
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 understand these were moved from tox.ini
, but what do you think about using the latest version of build tools instead of pinning these? It does mean dealing with some build unpredictability, but prevents us having to make big changes to update these packages later.
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 think we should at least have >=
requirements (although the minimum version would be very low due to Python 3.4 support most of the time, at least for requirements we use on Python != 3.7). I'm fine with removing upper bounds though.
for subdir in rootpath.iterdir(): | ||
if not subdir.is_dir(): | ||
continue | ||
if subdir.name.startswith(".") or subdir.name.startswith("venv"): |
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.
Using gitignore
or similar seems like a better long term solution here.
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.
True, actually since Python already supports globbing (and it's already used in that script), that should be a relatively simple change.
Quoting from
CONTRIBUTING.md
:Of course the script works on both Windows and Linux (py > sh 😄). I encourage you to try it out.
PS: Yes, I know that I created "an ad-hoc, informally-specified, bug-ridden, slow implementation of half of"
xargsfind -exec
.