Skip to content

Bring back module level variables - #10

Closed
priv-kweihmann wants to merge 2 commits into
aboutcode-org:mainfrom
priv-kweihmann:glob-mod-vars
Closed

Bring back module level variables #10
priv-kweihmann wants to merge 2 commits into
aboutcode-org:mainfrom
priv-kweihmann:glob-mod-vars

Conversation

@priv-kweihmann

Copy link
Copy Markdown

0c646b7 removed several
module level variables, although they are needed by downstream tools like scancode.
Bring them back in their py3 only variants.
Add test cases to avoid future regression

@pombredanne

Copy link
Copy Markdown
Member

@priv-kweihmann Good catch! If you need these let me reinstate them.

Eventually they should not longer be needed by the updates to ScanCode in this branch that are about to be merged anytime: aboutcode-org/scancode-toolkit#2365
... so that's potentially a timing issue: previous scancode versions do not have version ranges to use (but they have requirement files with pinned wheels though)

Comment thread src/commoncode/fileutils.py Outdated
def logger_debug(*args):
return logger.debug(' '.join(isinstance(a, str) and a or repr(a) for a in args))

PATH_TYPE = compat.unicode

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that compat is gone entirely and compat.unicode can just be replaced by str

@priv-kweihmann

Copy link
Copy Markdown
Author

@priv-kweihmann Good catch! If you need these let me reinstate them.

Eventually they should not longer be needed by the updates to ScanCode in this branch that are about to be merged anytime: nexB/scancode-toolkit#2365
... so that's potentially a timing issue: previous scancode versions do not have version ranges to use (but they have requirement files with pinned wheels though)

Alright, if something else unbreaks scancode I'm also fine with it - Let the first MR win :-)

0c646b7 removed several
module level variables, although they are needed by downstream
tools like scancode.
Bring them back in their py3 only variants

Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
to avoid future regressions

Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
@priv-kweihmann

Copy link
Copy Markdown
Author

On a second thought, I think this still should be merged, as otherwise we will still have downstream users (current released scancode) that does pulls the current version of commoncode automatically via pip.
Once scancode does actually don't require these vars anymore it's safe to revert these commits - with this you guys could control behavior via python versioning - without I see a lot of downstream jobs breaking for hard to explain reasons

@pombredanne

Copy link
Copy Markdown
Member

@priv-kweihmann I wanted to merge this still. I needed to push a release first. Do you think this is no longer an issue with the latest release?

@priv-kweihmann

Copy link
Copy Markdown
Author

I'm not having issues with the latest release in this regard (but with a lot of other things :-) ) - so IMO this MR can be closed as it isn't needed any more

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants