1)
File "/usr/lib/python-exec/python3.6/RigoDaemon_app.py", line 362, in _pusher
fobj.write(chunk)
TypeError: write() argument must be str, not bytes
2)
File "/usr/lib64/python3.6/site-packages/entropy/spm/plugins/interfaces/portage_plugin/__init__.py", line 77, in __init__
self.buffer = Writer(self, self._std.buffer)
AttributeError: 'FakeOutFile' object has no attribute 'buffer'
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).
This way there is no hardcoded /usr/lib/rigo, and the "executable" part
is in a well known location which can be replicated on system for
different Python implementations. (As in: it will be like /usr/bin/foo.py
which on Gentoo links to a system wrapper making it use configured
Python.)
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.
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
We need to monkey patch isMainThread in order to return True for
the ActionQueueWorkerThread as well. This avoids EntropySQLRepository
to initialize an infinite number of cleanup monitor threads for a
thread that will never go away (the ActionQueueWorkerThread one).
Sławomir Nizio
Ettore Di Giacinto
Fabio Erculiani
Ettore Di Giacinto
Dušan