- Replace deprecated Thread.isAlive() with is_alive() (Python 3.12)
- Fix invalid escape sequences in regex strings (SyntaxWarning → SyntaxError)
- Replace removed unittest aliases: assertEquals→assertEqual,
assertNotEquals→assertNotEqual, assert_→assertTrue,
assertRaisesRegexp→assertRaisesRegex (Python 3.12)
- Replace portage's removed clear_caches() with flush_cache()
- Fix locks.py: reset TLS state on exception in _file_lock_create
to prevent stale shared-lock state poisoning subsequent acquisitions
- Skip os.chown() when gid is None or caller lacks permission
- Fix FastRSS attribute ordering for consistent minidom re-parse behavior
- Update test expected XML to match Python 3.8+ minidom attribute order
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
This way a proper separation between Python installs can be achieved.
With no PYTHON_SITEDIR, installation paths are exactly the same as
before this change.
In practise, passing nonstandard path will break Entropy but so it is
also with the currently available LIBDIR. This is a concern of a future
improvement (at least the PYTHON_SITEDIR path, not necessarily LIBDIR as
PYTHON_SITEDIR *will* be different if it's installed in Python specific
directories).
For convenience (seemingly, and it really is convenient) equo and other
tools can be run from the checkout, and Entropy modules are loaded from
the checkout. Now there is a strict separation when system paths and
when paths from the checkout are used.
It makes it a bit more robust, secure and preditable at the cost of
a little more complexity.
A pleasant side effect of this change is that it is not required to
change directory to the tool (to use non-system one), as paths in the
checkout are relative to scripts.
Imports in lib/tests were not adjusted.
- Variable entropy_client was not available where it was used.
- Module entropy.dep was not imported but was used. It worked as
the module was imported from another place, but it is better to
import it explicitly.
Suggested by Ettore.
My comment is that it is to have a more correct information and to give
credit where it is due.
This is not a "miscredit" towards the Creator. We know who has made this
possible!
Examples of scenarios that are fixed:
- "package was installed by user" information was lost on package p1
when p1 was pulled as update on "equo install p2";
- update was saving all packages as installed by user.
In certain extreme situations, that are more likely if the install
state is old (e.g. 9 months +), Entropy may decide to remove packages
due to conflicts with the version being installed and shoot itself
in the foot, if this is the case of dev-lang/python :-).
So, this commit tries to avoid the scenario by filtering out package
removals for those that are being installed anyway as part of the
transaction (e.g. a system upgrade).
This should fix the very specific case, but increase uncertainty
and thus entropy in other cases where once a package that lists
conflicts is installed, it may not expect to find that package
installed. However, this case should be handled by the dependency
graph generator (and it currently does not), which would need to
reorder the execution of the queue to comply with conflicts.
Perhaps, someone in the future will improve that too, for now,
let's enjoy one more snowflake.
Current improvement:
- foo-1 and bar-2 are set to be installed
- foo-1 conflicts with <bar-2
- bar-1 is installed
- foo-1 wanted to remove bar-1 as part of foo-1 install transaction.
(now fixed, it won't...)
- bar-2 is then installed
Better improvement:
- foo-1 and bar-2 are set to be installed
- foo-1 conflicts with <bar-2 (but bar-2 itself can be installed
and does not conflict with foo-1)
- bar-2 is set to be installed before foo-1
- when entropy gets to foo-1 there is nothing to remove
