logilab-common merge requestshttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests2020-05-06T13:10:43Zhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/1Topic/default/types annotations and cleaning2020-05-06T13:10:43ZLaurent PeuchTopic/default/types annotations and cleaningHello,
This series is the result of our last sprint where we tested pyannotate to ...Hello,
This series is the result of our last sprint where we tested pyannotate to
generates types annotations from runtime analysis of our tests.:
https://github.com/dropbox/pyannotate
I've also included some cleaning work I was doing on the side when trying to do
this damn refactoring on yams was breaking my brain a bit too much.
To give a feedback on using pyannotate as a tool to introduce types annotations
in a project in comparison from doing everything by hand:
- it totally save a lot of time in comparison of doing everything by hand
- it's clearly not out of the box, we've had to fix some stuff from the
generated analysis and then to please mypy (and it tooks me a few days to
finish this work)
- but it's still worth it has it automates a lot what I was doing by hand
- it doesn't have the quality of doing everything by hand and checking
everything by hand but it's still a win to start introducing types
- for our case it's based on tests data so it might not be perfect
For this series I've been focusing only on making mypy happy from the generated
types so it's clearly not optimal but I will definitively used pyannotate again
as a good way to bootstrap adding type annotations to a project.
This series also include the common list of good practices that are starting to
be included in all logilab's projects:
- black integration taken from yams that was taken from nemo
- flake8 compatible with black from the same source
- fyi I've tested https://github.com/myint/autoflake for flake8 cleaning, it
helps a bit but doesn't do a lot of works
- check-manifest integration
- some minor cleaning raised by mypy/flake8 regarding python3 compatibility
Kind regards,Laurent PeuchLaurent Peuchhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/3new rename utils2020-04-30T08:22:05ZLaurent Peuchnew rename utilsHello,
This MR introduction 3 news deprecation utils needed for a smooth "let's purge all abbreviations with fire" work that we are doing on YAMS schema.py right now, they are:
- `deprecation.argument_renamed(old_name, new_name)`
...Hello,
This MR introduction 3 news deprecation utils needed for a smooth "let's purge all abbreviations with fire" work that we are doing on YAMS schema.py right now, they are:
- `deprecation.argument_renamed(old_name, new_name)`
- `deprecation.attribute_renamed(old_name, new_name)`
- `deprecation.renamed(old_name, new_function)`
- `deprecation.argument_removed(old_name)`
This can be merged before https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/1 has it is needed sooner. I'll handle the rebasing part (:cry:).
Kind regards,Fabien Amargerfabien.amarger@logilab.frFabien Amargerfabien.amarger@logilab.frhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/4simplify deprecation module2020-04-30T14:52:32ZLaurent Peuchsimplify deprecation moduleBasically a refactoring of the whole module to simplify it a lot removing the never used overkill `DeprecationManager` class and move to just a list of simple function.
I've backported from `DeprecationManager` the principle of displa...Basically a refactoring of the whole module to simplify it a lot removing the never used overkill `DeprecationManager` class and move to just a list of simple function.
I've backported from `DeprecationManager` the principle of displaying the module in which the warning is fired by making it automatic using frame walking.
Also, as discussed with Nicolas, we should probably extract this from logilab-common into a new standalone python module like most of the modules of logilab-common, having everything bundle doesn't make that much sens anymore.Elodie ThiéblinElodie Thiéblinhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/5fix(deprecation): new_function must be a callable, not a string2020-05-04T07:18:49ZSimon Chabotfix(deprecation): new_function must be a callable, not a stringLaurent PeuchLaurent Peuchhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/6[tox] Use tox to launch test in the Jenkins pipeline2020-05-07T10:15:48ZFabien Amargerfabien.amarger@logilab.fr[tox] Use tox to launch test in the Jenkins pipelineLaurent PeuchLaurent Peuchhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/7[deprecation/fix] correctly automatically get the module in which deprecation...2020-05-06T19:09:43ZLaurent Peuch[deprecation/fix] correctly automatically get the module in which deprecation utils are calledThere was a missmatched combination of:
* the frame wasn't always correctly grabbed
* grabbing the frame in the situation of a decorator didn't make any sens, so
switch to func.__module__
* the tests were bad and expected "[logil...There was a missmatched combination of:
* the frame wasn't always correctly grabbed
* grabbing the frame in the situation of a decorator didn't make any sens, so
switch to func.__module__
* the tests were bad and expected "[logilab.common]" while it should have been
"[test_deprecation]" because it was there that the depreciation was declaredhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/8Topic/default/fix deprecation grabbing module2020-05-07T09:48:32ZLaurent PeuchTopic/default/fix deprecation grabbing moduleBrigging back https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/7 because heptapod is doing weird things with topics
There was a missmatched combination of:
* the frame wasn't always correctly grabbed
* gra...Brigging back https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/7 because heptapod is doing weird things with topics
There was a missmatched combination of:
* the frame wasn't always correctly grabbed
* grabbing the frame in the situation of a decorator didn't make any sens, so switch to func.module
* the tests were bad and expected "[logilab.common]" while it should have been "[test_deprecation]" because it was there that the depreciation was declaredhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/9[fix] logilab-common requires python 3.6 now2020-05-11T06:47:32ZLaurent Peuch[fix] logilab-common requires python 3.6 nowFixes #2Fixes #2https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/10class deprecated metaclass conflict2020-05-15T16:13:01ZLaurent Peuchclass deprecated metaclass conflictHello,
Has describe in the test if you have different metaclass this will break all this current code. There was a situation before that was here to handle compatibility with python2 which by side effect solve this issue, see https://fo...Hello,
Has describe in the test if you have different metaclass this will break all this current code. There was a situation before that was here to handle compatibility with python2 which by side effect solve this issue, see https://forge.extranet.logilab.fr/open-source/logilab-common/blob/1.5.2/logilab/common/deprecation.py#L126
While doing this I realized that the previous solution was actually way simpler and didn't present this bug and I don't understand why it has been chosen to move to a metaclass strategy so I simply went back to this previous approach.
This situation breaks CubicWeb sadly, I'm going to see if we can launch tests from other project in this CI to see if we breaks them.
Kind regards,https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/12[fix] metaclass conflict for class_deprecated2020-05-13T16:15:44ZLaurent Peuch[fix] metaclass conflict for class_deprecatedHello,
This is a backport of https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/10 for the 1.6 branch to release a 1.6.3 since this has caused bugs in some clients projects.
@schabot do you think you could do a...Hello,
This is a backport of https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/10 for the 1.6 branch to release a 1.6.3 since this has caused bugs in some clients projects.
@schabot do you think you could do a release with that one?
Kind regards,Simon ChabotSimon Chabothttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/14fix: restore strptime, but set a deprecation warning2020-05-25T07:18:55ZSimon Chabotfix: restore strptime, but set a deprecation warningwait a little bit before removing strptime from logilab.common. Some projects imports this.wait a little bit before removing strptime from logilab.common. Some projects imports this.https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/15Topic/1.6/fix cubicweb isinstance class deprecated2020-05-25T07:18:50ZLaurent PeuchTopic/1.6/fix cubicweb isinstance class deprecated@schabot that's the rollback we've made to not break CW@schabot that's the rollback we've made to not break CWhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/16Fix usage of callable_deprecation on LazyObject that was breaking CW 3.24 (or...2020-05-25T15:53:41ZLaurent PeuchFix usage of callable_deprecation on LazyObject that was breaking CW 3.24 (or something like that)So, brace yourself, it's a little bit complicated (don't hesitate to reach me for more explanation).
So, it goes like that:
- I've introduced the usage of the `@wraps` decorator from functools.wraps in logilab.common.deprecation.callab...So, brace yourself, it's a little bit complicated (don't hesitate to reach me for more explanation).
So, it goes like that:
- I've introduced the usage of the `@wraps` decorator from functools.wraps in logilab.common.deprecation.callable_deprecated because this is a good practice
- turns out if broke francearchives code
- which is because it uses an old version of CW
- in this old version of CW, logilab.common.modutils.LazyObject is used (well, inherited) here https://forge.extranet.logilab.fr/cubicweb/cubicweb/blob/3.24.0/cubicweb/schemas/__init__.py#L51
- LazyObject all you to do something like `exists = LazyObject("os.path", "exists")` and up until `exists` is used, the import is not triggered
- here "used" means "access attributes or call it"
- so, CW uses (My)LazyObject to prepare to import a bunch of cubes (but not importing them) and mark them as callable_deprecated
- this allow to raise a deprecation warning if they are used but not add those cubes as dependencies in CW
Now, why is it a problem? Well ...
- turns out: `functools.@wraps` actually try to access a bunch of attributes on the wrapped callable to grab `__name__`, '__dict__`, '__doc__` to avoid breaking a bunch of stuff
- going back to before, you might have guessed it: by trying to access those attributes, `functools.@wraps` triggers the import of those objects
- which in turns breaks everything because this is supposed to be a lazy import and so it was supposed to handle the case where those dependencies weren't installed
- and you get an ImportError and your code doesn't work anymore
So, this MR:
- recreate the behavior of functools.wraps but in a lazy way to solve this issue
- it also ensure that we never access attributes of the decorated callable before this decorated callable is actually called
- document LazyObject because pffff
I think it's the first time I had to debug one exception that triggered 3-4 other exceptions ^^'
Also protip: uses pdbpp instead of pdb, it allows to access hidden frames.https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/17[for default] Fix usage of callable_deprecation on LazyObject that was breaki...2020-05-25T15:53:47ZLaurent Peuch[for default] Fix usage of callable_deprecation on LazyObject that was breaking CW 3.24 (or something like that)Same as https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/16 but for the default branch.Same as https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/16 but for the default branch.https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/18[doc] update Changelog2020-06-02T12:29:39ZLaurent Peuch[doc] update ChangelogAdd missing latest versions.Add missing latest versions.https://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/19refactor(logilab.common.deprecation): add types2020-06-10T15:37:18ZLaurent Peuchrefactor(logilab.common.deprecation): add typesResult of our sprint Friday (and with the Protocol stuff added)Result of our sprint Friday (and with the Protocol stuff added)Fabien Amargerfabien.amarger@logilab.frFabien Amargerfabien.amarger@logilab.frhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/20fix doc generation2020-06-10T12:10:31ZLaurent Peuchfix doc generationBecause cachedproperty does magic with __doc__ it broke sphinx static analyse because it expect __doc__ to be a string and doing cachedproperty.__doc__ returns an uninitiliazerd property, not the string.Because cachedproperty does magic with __doc__ it broke sphinx static analyse because it expect __doc__ to be a string and doing cachedproperty.__doc__ returns an uninitiliazerd property, not the string.Elodie ThiéblinElodie Thiéblinhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/22fix(typing): Explicitly define Match and Pattern on Import Error (python < 3.7)2020-06-11T07:42:41ZSimon Chabotfix(typing): Explicitly define Match and Pattern on Import Error (python < 3.7)for python < 3.6 those two types are not defined. In case of import error, let's
define them (in the exact same way they are defined in the re module of python
>= 3.7).for python < 3.6 those two types are not defined. In case of import error, let's
define them (in the exact same way they are defined in the re module of python
>= 3.7).Laurent PeuchLaurent Peuchhttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/23[deprecation/fix] rollback to old class_deprecation being a class behavior2020-06-23T13:04:50ZLaurent Peuch[deprecation/fix] rollback to old class_deprecation being a class behaviorIt breaks CW because CW was using class_deprecated in a isinstance to select the good views to uses.
Rollback this change everywhere because it breaks too many things.It breaks CW because CW was using class_deprecated in a isinstance to select the good views to uses.
Rollback this change everywhere because it breaks too many things.Simon ChabotSimon Chabothttps://forge.extranet.logilab.fr/open-source/logilab-common/-/merge_requests/24[deprecation/fix] rollback to old class_deprecation being a class behavior2020-06-23T13:04:34ZLaurent Peuch[deprecation/fix] rollback to old class_deprecation being a class behaviorSame than https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/23
We'll need to release a 1.7.1 for this one if possibleSame than https://forge.extranet.logilab.fr/open-source/logilab-common/merge_requests/23
We'll need to release a 1.7.1 for this one if possibleSimon ChabotSimon Chabot