Function callers, in order (during eit commit):
1. filename='lib/entropy/server/interfaces/main.py', function='switch_default_repository', code_context=[' self.close_repositories()\n'], index=0)
2. filename='server/eit/commands/command.py', function='_call_exclusive', code_context=[' server.close_repositories()\n'], index=0)
3. filename='lib/entropy/client/interfaces/client.py', function='destroy', code_context=[' self.close_repositories(mask_clear = False)\n'], index=0)
4. filename='lib/entropy/server/interfaces/main.py', function='destroy', code_context=[' self.close_repositories()\n'], index=0)
Third one triggers packages set synchronization (which would cause "dictionary
changed size during iteration"), and marks sets as being synchronized.
Fourth does not trigger sets synchronization, so closes all repositories
without new ones being opened in the meantime.
Side note:
It's similar to this in "client," lib/entropy/client/interfaces/methods.py:
def close_repositories(self, mask_clear = True):
...
# list() -> python3 support
for item, val in list(repo_cache.items()):
...
repo_cache.pop(item).close(_token = repository_id)
...
but (based on shallow look), it doesn't do as much magic; just calls .pop()
(not sure if there are similar side effects in close() there, though), so the
explanation may possibly apply to the lib/entropy/server function only.
1. Command to execute (diff) was getting arguments like b"path".
2. Crash when priting message.
3. In Python 3, b'x'[0] is int, not str, so a test (if) was (silently)
always true. This way, upon eit commit (at least) and with Python 3,
warning about not merged configuration files was newer printed.
(3) prevented prior discovery of (1) and (2).
Based on my checks, there are no more problems like (3), but I cannot
tell for sure.
[Not tagged so in their git repository... whatever.]
With -R / it prints bogus lines making Entropy crash:
File "/usr/lib64/python2.7/site-packages/portage/dbapi/vartree.py", line 748, in aux_get
raise KeyError(mycpv)
KeyError: 'plib_registry:'
The change was done in portage-utils, commit f05c78008b1754a79e31e793a67d07ed8f5d11bc
Make qfile also check the prune lib registry
and the problem with qfile was reported to Gentoo in bug 699558.
It will break with older qfile but Entropy should fallback to slower,
non-qfile code branch.
In 0.74 -e was available, and in 0.80 it is not present.
In both versions, and with the same set of options used, -e and -v
provide the same result so -v is now used to work on both.
Changed in portage-utils, commit 951a8711a59b1a7d49125f5f5214ff1ae9e50074:
qfile: drop non-functional --exact option
Bug: https://bugs.gentoo.org/678632
Note: <tab> below can mean double <tab>.
This commit fixes cases such like the following ones:
* crash (issue !73) - e.g. KeyError: u'--mtime':
- equo security oscheck --mtime <tab>
- equo query graph --complete <tab>
(this was due to a typo in variable name)
* now prints options, previously it didn't:
- equo install -a <tab>
* crashed, or (with only variable name fixed) didn't print all options:
- equo security oscheck --mtime <tab>
(note that it worked with more special -q instead of --mtime etc.)
* didn't print all options:
- equo query list installed <tab>
(now shows also --by-user)
The following behaviour is still buggy:
* last typed word (note: no space before <tab>) disappears upon completion:
- equo security oscheck<tab>
(not a regression)
- equo install --deep<tab>
(here it's an option; regression! - previously it didn't complete but
didn't cause the word to be erased either)
These can be corrected reliably when something like ${COMP_WORDS[COMP_CWORD]}
(from complete -F) is passed to the Python side.
Without this it's not possible to distinguish between `recognized_option<tab>`
(completion of recognized_option) and `recognized_option <tab>`.
The module entropy_path_loader (used only for running from within the
checkout; otherwise not even installed) is made to provide the _entropy
namespace.
(Other ideas instead of this entropy_path_loader change would be to
reorganise files layout; drop support for running from the checkout as
is - and perhaps require virtualenvs; require sourcing a script that
sets PYTHONPATH. However, as implemented, it is not intrusive, and the
good part is that it is quite isolated, not used in normal usage after
installation. Basically, it only does sys.path + provides _entropy
namespace.)
The idea is that:
- entropy.* imports will work as before (so any 3rd party clients will
work as always) - installed in "entropy" package,
- new "_entropy" package to hold a namespace for private modules (like
ones that required adding special directories to sys.path).
(Underscored name for a top level Python module is not very common...
anyway, it was inspired by "_emerge.")
Layout:
site-packages/
entropy (backwards compatible)
const.py
...
kswitch (also toplevel to keep compatibility)
...
_entropy
eit
magneto
matter
rigo
RigoDaemon
solo
(Note that site-packages does not need to be actually Python's
site-packages directory but anything as it is controlled by an argument
to make. It is however intended to be the sitedir.)
Another idea for a layout would be one that mimics sources checkout, but
the layout there is somewhat scattered. (And some ugliness would be
needed to make them modules before implicit namespaces from Python 3.3.
Anyway, imports would be long and ugly.)
Now, the layout of installed Entropy is lean; installation to virtualenv
is also possible (though there would be a need to call scripts like
"python equo.py" as shebangs are not converted).
Follow up changes are needed to make it work.
After this commit alone it would not work when installed (unless module
paths are set in a special way). Next changes will introduce
installation to site-packages so no custom PYTHONPATH will be necessary.
Sławomir Nizio
Ettore Di Giacinto
Ettore Di Giacinto
geaaru
Geaaru