-
Notifications
You must be signed in to change notification settings - Fork 973
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
Only use setup.py
#981
Only use setup.py
#981
Conversation
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 like the change, but it is broken in some ways:
preset_loader
(from local moduleconfig_helpers
) is not installed. Theconftest
errors.- when running
make install_test
on a clean repo, it generates apyspec.egg-info
, something I don't have in my global git ignore, and many other non-python contributors as well. May just want to add it to the.gitignore
You can try by doing a make clean
, and then a test-run. Not sure why the CI didn't catch it.
00f97f5
to
05c805a
Compare
Ready for another look!
I think CI didn't raise due to the cache. My current workaround is:
IMO the better solution may be using one single
Updated |
eb6007e
to
02e6d5b
Compare
1. Move .venv to TEST_LIBS_DIR/ 2. Install `config_helpers` separately
I messed up and merged this into proto's branch by accident. sorry! |
@djrtwo 😆 I'm not sure what happend. My understanding is:
I guess you wanted to revert it in |
Yup, messed this one up.. |
Important comment: #1020 (comment) |
Mostly yes. It was reverted, because the solution breaks testing from a clean install. And although the partial solution was nice & reviewed, it didn't cover everything, and was merged prematurely.
Well, CI testing is one thing. Agree that that can be cleaner. But we don't change it often, And I prefer having fast tests for 95% of the other PRs. The issue is installing packages doesn't fully work with
Not on the same page here. When you combine packages, you mix up dependencies. Some solutions are packaged separately, as to not put unrelated code in the scope of the modules consuming the dependencies.
Not a fan of this honestly. IF we were looking to go full software release-cycle, we wouldn't be writing a "specification". In the software case: then also just break some of those readability-performance issues, and make it actually viable to use directly.
I do like the Alternative solutionThere is another approach, which keeps things minimal, non-duplicate, and fixes some confusion in the process of the installing when using an IDE: just use The idea of TLDR:So unless there is a way to introduce local requirements into |
PR feedback of #979. We can only use
setup.py
instead of separating requirements files.