-
Notifications
You must be signed in to change notification settings - Fork 12
⚠️ CONFLICT! Lineage pull request for: skeleton #44
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
setuptools usually comes along with pip, but wheel does not. Using wheel where possible to build python extensions is more modern and more security conscious than using setup.py.
Add setuptools and wheel as pip dependencies
6605b2c
to
e211491
Compare
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.
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 have a question 🖐️
requirements-test.txt
Outdated
@@ -1 +1,3 @@ | |||
--requirement requirements.txt | |||
-e .[test] | |||
pre-commit |
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 the pre-commit
dependency be part of the test
section in setup.py
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.
pre-commit
is in the test
section, but I wasn't sure if we wanted to leave it in requirements-test.txt
in case something changes with the configuration in setup.py
. I'm happy to remove it from requirements-test.txt
if we want to leave it to the setup.py
configuration.
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.
Let's remove it from requirements-test.txt
so we have a single source of truth.
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.
Please see 370f2a2 for that change.
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.
See comments.
requirements.txt
Outdated
@@ -1 +1,3 @@ | |||
-e . | |||
setuptools |
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 requirements should be added to the main section of setup.py
. If we have a setup.py
file then the requirements*.txt
files should just call that so we have a single source of truth.
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 wheel
should remain in requirements.txt
because it is an environment preference and not something required for the project to function. Per packaging documentation:
install_requires
is a setuptoolssetup.py
keyword that should be used to specify what a project minimally needs to run correctly.
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 removed setuptools
from requirements.txt
in 370f2a2.
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.
Can @felddy, @dav3r, and @hillaryj weigh in here? We should do the same thing everywhere, and @felddy and I added wheel
to setup.py
in cisagov/development-guide#21.
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 have no preference here. @mcdonnnj makes a good point about wheel
being a preference vs. being required, but I'm not sure it makes a big difference either way in this case. I'll go with whatever the group decides on this one.
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.
@mcdonnnj makes a good point, but I also like having a single source of truth. I think mixing dependencies between requirements*.txt
and setup.py
files will eventually lead to confusion. I think simplicity trumps his argument in this case, but I will also concede to whatever the group decides.
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 would like to point out that we already do this with requirements-dev.txt
where ipython
and semver
are described as preferences for a development environment. They are not necessary for the functionality of the package, but are used for development.
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, you have convinced me. Can you create a PR to do the same thing in cisagov/development-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.
I approve this train of... thought. 🧠 🚂
ALL ABOARD THE BRAIN TRAIN!!! WOO WOO!
…ngle Source of Truth.
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.
☸️
Lineage Pull Request: CONFLICT
Lineage has created this pull request to incorporate new changes found in an
upstream repository:
Upstream repository:
https://github.com/cisagov/skeleton-generic.git
Remote branch:
HEAD
Check the changes in this pull request to ensure they won't cause issues with
your project.
The
lineage/skeleton
branch has one or more unresolved merge conflictsthat you must resolve before merging this pull request!
How to resolve the conflicts
Take ownership of this pull request by removing any other assignees.
Clone the repository locally, and reapply the merge:
Review the changes displayed by the
status
command. Fix any conflicts andpossibly incorrect auto-merges.
After resolving each of the conflicts,
add
your changes to the branch,commit
, andpush
your changes:Wait for all the automated tests to pass.
Check the "Everything is cool" checkbox below:
Mark this draft pull request "Ready for review".
Note: You are seeing this because one of this repository's maintainers has
configured Lineage to open pull requests.
For more information:
🛠 Lineage configurations for this project are stored in
.github/lineage.yml
📚 Read more about Lineage