-
Notifications
You must be signed in to change notification settings - Fork 12
Fixed regression in handling of imports (fixes #160) #161
Conversation
shmeate_schmarning = warn | ||
|
||
|
||
def create_warm_things(**kwargs): |
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 whole file is great, but this is the best line.
I think this PR is stalled because Travis is struggling (microsoft/LightGBM#2954 (comment)) |
closing and re-opening to retrigger CI correctly. Travis had an outage today caused by a GCP outage. |
Codecov Report
@@ Coverage Diff @@
## master #161 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 6 6
Lines 316 316
=====================================
Hits 316 316 Continue to review full report at Codecov.
|
I think the travis outage has left this PR in a weird state. Also they had this incident yesterday: I can clearly see that the build passed: https://travis-ci.org/github/jameslamb/doppel-cli/builds/667965392, so I'm going to use executive power and merge. |
In this PR, I attempted to fix the issue @austin3dickey raised in #160 . The fix here returns
doppel-cli
's handling of standard-lib functions (e.g.from warnings import warn
) to the previous behavior.I added @austin3dickey's reproducible example as a test package and added tests on it. Note that in those tests, I'm not taking a stand on what the behavior should be, just trying to document the current behavior so regressions like this aren't accidentally introduced in the future.
For example, right now I know that
doppel-cli
isn't doing the "right" thing for a package likefeather
, where it seems obvious that they are trying to "re-export" from other packagesAs of this commit, running
doppel-describe -p pythonspecific2 -l python -d out/
yields:I tested with
doppel-cli==0.2.1
and got the exact same output.The tests are passing for the other built-in cases I tried to address in #155 so I don't think this is undoing that work.