-
Notifications
You must be signed in to change notification settings - Fork 13
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
v0.32.0 #367
Conversation
Codecov Report
@@ Coverage Diff @@
## master #367 +/- ##
===========================================
+ Coverage 65.19% 88.12% +22.92%
===========================================
Files 14 10 -4
Lines 1428 1187 -241
===========================================
+ Hits 931 1046 +115
+ Misses 497 141 -356
Continue to review full report at Codecov.
|
- Project init performance enhancements - add progress bars for large Projects - fix import warnings
@stolarczyk Just need a quick comment on this -- right now the tests are failing because
Shouldn't the same object be used for 2.0.0 and 2.1.0 since they are backwards compatible? I just want to confirm that this is an error in the version checking, and not in the actual PEPs, since that doesn't make sense to me. |
I don't remember exactly what behavior did we decide on. I agree that it would be great if one object could accommodate both versions. In 2.1.0 the Project object can be created based on sample table, no project config is needed. |
a separate object for 1.0 vs 2.0 makes sense to me, but not for 2.1 vs 2.0. You had this working with all the 2.1 updates, before we decided to increment the spec to 2.1. Are you saying to update the spec you moved that all into a separate object so 2.0 and 2.1 are separate? I don't quite understand. I think the issue is more likely just that you didn't update the tests -- but look, tests passed in your previous commit (the one prior to the last commit on this branch, which is what broke the tests. |
@stolarczyk I'm still not sure what you were intending here so any guidance would be appreciated. |
This commit solves most of the tests by not requiring the pep version to be 2.1.0. However, there are 2 tests that still fail because no pep version is included. Can you explain what you're trying to do here? In your tests, you load a version 1 PEP, I guess with a version 2 object, and then it complains that it lacks the version key. But version 1 PEPs aren't supposed to have the version key. So I guess this is just another error with the tests? |
There are now 2 duplicates of the project code: in pep200/project.py is, I guess the "old" version -- which handles PEP version 1.0. I am just confused at the naming here; why did you make pep200 the one that handles PEP 1.0? Is it just a naming error and that should be pep100? The main project in peppy/project.py handles either 2.0 or 2.1 PEPs. |
Looks good to me. Make sure it's tested with looper before release. |
@nleroy917 Are you satisfied that this is working in your use case? |
Yes it looks good to me |
getting ready to release... |
todo