fix: Added const module to base namespace.

[valentingregoire]

Changes

Documentation and testing

Please consider whether this PR needs documentation and tests. This is not required, but highly appreciated:

• Documentation in the matching docs section
• Unit tests and/or functional tests

[valentingregoire]

See #2819.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.51%. Comparing base (7ec3189) to head (2f47909).
Report is 71 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2820      +/-   ##
==========================================
- Coverage   96.52%   96.51%   -0.02%     
==========================================
  Files          90       90              
  Lines        5872     5874       +2     
==========================================
+ Hits         5668     5669       +1     
- Misses        204      205       +1     

Flag	Coverage Δ
api_func_v4	82.22% <100.00%> (-0.02%)	⬇️
cli_func_v4	83.63% <100.00%> (+0.05%)	⬆️
unit	88.28% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
gitlab/__init__.py	100.00% <100.00%> (ø)

[nejch]

Thanks for the PR @valentingregoire! AFAIK this was an intentional change at some point to enforce namespacing the constants, as the number of package-level exports kept growing. Or am I forgetting something, do you remember @JohnVillalovos?

In any case I don't mind this but perhaps we should avoid exporting the deprecated strings that have been replaced by enums.

[JohnVillalovos]

That is what I remember @nejch

[valentingregoire]

@nejch, @JohnVillalovos, I see that this could be the intention, indeed. Would it then make sense to add the const module to the root __init__ here? Else it is not properly exported, no?

[nejch]

@nejch, @JohnVillalovos, I see that this could be the intention, indeed. Would it then make sense to add the const module to the root __init__ here? Else it is not properly exported, no?

@valentingregoire modules are not exported in __all__ like that at least to my knowledge. Either we re-export them again at top-level or keep the current namespaced imports.

You simply do one of the folllowing:

# module import with full namespace
import gitlab.const
gitlab.const.AccessLevel.ADMIN
<AccessLevel.ADMIN: 60>

# module import
from gitlab import const
const.AccessLevel.ADMIN
<AccessLevel.ADMIN: 60>

# class import
from gitlab.const import AccessLevel
AccessLevel.ADMIN
<AccessLevel.ADMIN: 60>

Does this not work for you?

[valentingregoire]

@nejch, yes that works perfectly fine. It's just that it's a bit inconsistent with the exceptions that are added to the global namespace, where the constants are not. For example:

from gitlab import GitlabGetError
from gitlab.const import MAINTAINER_ACCESS

This feels a bit weird and inconsistent. Maybe the correct solution is either to leave everything as is, or to put the exceptions out of the global namespace. This would be another major change though...

[nejch]

@nejch, yes that works perfectly fine. It's just that it's a bit inconsistent with the exceptions that are added to the global namespace, where the constants are not. For example:

from gitlab import GitlabGetError
from gitlab.const import MAINTAINER_ACCESS

This feels a bit weird and inconsistent. Maybe the correct solution is either to leave everything as is, or to put the exceptions out of the global namespace. This would be another major change though...

@valentingregoire a lot of python libraries seem to export exceptions at the root package level as a convention, but true if we want to be really consistent here we would leave them out in just gitlab.exceptions the same way that e.g. boto3 does. If we do this I would first go with a deprecation like we did for the constants. I'll leave it to you to decide as you were the first to report this :)