When attempting to store data with vault_archive under python 3.6, the following issue happens:
Traceback (most recent call last): File "test.py", line 53, in <module> store() File "test.py", line 25, in store vault_data = api.Command.vault_archive(u'asymm_vault_test', service=service, data="meow") File "/opt/vault_venv/lib64/python3.6/site-packages/ipalib/frontend.py", line 447, in __call__ return self.__do_call(*args, **options) File "/opt/vault_venv/lib64/python3.6/site-packages/ipalib/frontend.py", line 475, in __do_call ret = self.run(*args, **options) File "/opt/vault_venv/lib64/python3.6/site-packages/ipalib/frontend.py", line 1199, in run return self.forward(*args, **options) File "/opt/vault_venv/lib64/python3.6/site-packages/ipaclient/plugins/vault.py", line 896, in forward public_key = vault['ipavaultpublickey'][0].encode('utf-8') AttributeError: 'bytes' object has no attribute 'encode'
After doing some digging, the relevant issue is here, from ipaclient/plugins/vault.py:
elif vault_type == u'asymmetric': public_key = vault['ipavaultpublickey'][0].encode('utf-8')
If I apply the same style fix as with https://pagure.io/freeipa/c/436d2de456c14c869c9970fb53c2931c7c8e67c8, I am able to appropriately store data and it seems to be working fine under py2.7 as well.
This is appropriate for https://pagure.io/freeipa/issue/7131
Hi,
with which version did you see this issue? I could not reproduce with the master branch, probably because the issue you are seeing is a duplicate of #7033 which was fixed with commit 9cead4d.
Okay, this is confusing me.
I see the issue is in fact resolved in github in AUGUST, but ipaclient / ipalib / ipapython 4.5.2 pulled from pip on November 5th does not have these fixes.
In case there was some sort of glitch I re-ran pip install -U freeipa, and it still wants to stay on 4.5.2 with this damage.
Is there a distribution issue here or am I making a mistake?
4.5.x series are not compatible with python3. Python3 compatibility is provided starting with freeIPA 4.6. According to https://pypi.python.org/pypi/ipaclient/4.6.0, both py2 and py3 versions are available in pip.
Our PyPI packages are in dire state since September. 4.6.0 on PyPI is completely broken. 4.5.2 is the last version that actually works. We haven't released any version on PyPI that properly works with Python 3.
Please note that 4.5.2 also states that it is compatible with Python 3, https://pypi.python.org/pypi/ipaclient/4.5.2 . Apparently that is not true for all features.
That explains that. Though adding to the confusion is that the pypy version is explicitly labeled as python 3 supporting.
So should I be pulling the client libraries out of github directly?
On Wed, Dec 6, 2017 at 2:49 AM, Christian Heimes pagure@pagure.io wrote:
cheimes added a new comment to an issue you are following: Our PyPI packages are in dire state since September. 4.6.0 on PyPI is completely broken. 4.5.2 is the last version that actually works. We haven't released any version on PyPI that properly works with Python 3. To reply, visit the link below or just reply to this email https://pagure.io/freeipa/issue/7294
cheimes added a new comment to an issue you are following: Our PyPI packages are in dire state since September. 4.6.0 on PyPI is completely broken. 4.5.2 is the last version that actually works. We haven't released any version on PyPI that properly works with Python 3.
To reply, visit the link below or just reply to this email https://pagure.io/freeipa/issue/7294
ipa-4-5:
master:
ipa-4-6:
The upcoming 4.5 and 4.6 releases will contain Python compatibility markers. The vault issue will be fixed by next 4.6 release, too. 4.5 is not Python 3 compatible.
Metadata Update from @cheimes: - Issue assigned to cheimes
wheels for ipa 4.6.3 are available on PyPI. They should be fully compatible with Python 3.5+. Please open another issue in case you run into further bugs.
Metadata Update from @cheimes: - Issue close_status updated to: fixed - Issue set to the milestone: FreeIPA 4.6.3 - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.