Closed M0dM closed 10 months ago
@berdario, @tjanez, what do you think about this pull request ?
I do not kniw if it is best way to deal with the issue, but currently it is the way I found to make pew working with pythonz for python versions with two digits minor version.
I'd rather see this fixed in pythonz-bd, or better still (given that as I understand it @berdario no longer has time for open source work) back into the original pythonz, which we can then use directly. Does anyone know why we use a forked version of pythonz in the first place?
Disclaimer: I use Windows, and pythonz doesn't work on Windows, so I don't have any direct interest in this functionality.
Does anyone know why we use a forked version of pythonz in the first place?
I integrated pythonz in September 2015
https://github.com/pew-org/pew/commit/2e6ade830676b37bf355a2eef97fcb9b94c655e4
I was waiting for this pull request to be merged, that finally happened in November 2015:
https://github.com/saghul/pythonz/pull/91
Why didn't I switch back to the upstream version afterwards? Maybe the change was merged but there was no release on pypi? Maybe there was something else that I was waiting to be addressed? ...I can't remember 😅
Anyhow, if people don't see any glaring issue with the upstream pythonz, I'm not opposed to switch back to it.
It does not seems to be possible to install upstream pythonz using pip, and it seems upsteam pythonz have the exact same problem:
~/Git/pew (master)$ pythonz install 3.10
WARNING: Unsupported Python version: `3.10`, trying with the following URL anyway: http://www.python.org/ftp/python/3.1/Python-3.10.tgz
Traceback (most recent call last):
File "/home/benoit/.local/share/virtualenvs/pew/lib/python3.11/site-packages/pythonz/downloader.py", line 100, in read_head_info
res = urlopen(req)
^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 216, in urlopen
return opener.open(url, data, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 525, in open
response = meth(req, response)
^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 634, in http_response
response = self.parent.error(
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 557, in error
result = self._call_chain(*args)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 496, in _call_chain
result = func(*args)
^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 749, in http_error_302
return self.parent.open(new, timeout=req.timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 525, in open
response = meth(req, response)
^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 634, in http_response
response = self.parent.error(
^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 563, in error
return self._call_chain(*args)
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 496, in _call_chain
result = func(*args)
^^^^^^^^^^^
File "/usr/lib/python3.11/urllib/request.py", line 643, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 404: Not Found
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/benoit/.local/share/virtualenvs/pew/lib/python3.11/site-packages/pythonz/commands/install.py", line 104, in run_command
p.install()
File "/home/benoit/.local/share/virtualenvs/pew/lib/python3.11/site-packages/pythonz/installer/pythoninstaller.py", line 190, in install
headerinfo = Downloader.read_head_info(self.download_url)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/benoit/.local/share/virtualenvs/pew/lib/python3.11/site-packages/pythonz/downloader.py", line 102, in read_head_info
raise DownloadError('Failed to fetch %s' % url)
pythonz.downloader.DownloadError: Failed to fetch http://www.python.org/ftp/python/3.1/Python-3.10.tgz
https://github.com/saghul/pythonz/pull/176 is supposed to be the fix, but it doesn't look like pythonz has had a release since 2016. So I'm not sure pythonz
can be considered as still supported, even if they are merging fixes.
I don't really know what to do here. If pythonz-bd
is maintained, the fix can go in there. If it's not, then personally, I think we should simply drop pew install
rather than trying to somehow maintain a patched version of the patched version of the original. But that's easy for me to say as the feature isn't of any use to me. We should see what the other maintainers think.
Disclaimer: I'm on record as saying that if I were deciding the direction pew should evolve in, I'd drop pew install
anyway. But I've not had any explicit support from the other maintainers for that view, so I consider that as my personal opinion, not as any sort of policy.
saghul/pythonz#176 is supposed to be the fix, but it doesn't look like pythonz has had a release since 2016. So I'm not sure
pythonz
can be considered as still supported, even if they are merging fixes.I don't really know what to do here. If
pythonz-bd
is maintained, the fix can go in there. If it's not, then personally, I think we should simply droppew install
rather than trying to somehow maintain a patched version of the patched version of the original. But that's easy for me to say as the feature isn't of any use to me. We should see what the other maintainers think.Disclaimer: I'm on record as saying that if I were deciding the direction pew should evolve in, I'd drop
pew install
anyway. But I've not had any explicit support from the other maintainers for that view, so I consider that as my personal opinion, not as any sort of policy.
I think, it could be a good idea to drop pew install
as pythonz and pew can work all together without this command.
Maybe adding a few lines in the README with the command below could be a good idea :
pythonz install 3.11.6
pew new -p $(pew locate_python 3.11.6) venv_name
saghul/pythonz#176 is supposed to be the fix, but it doesn't look like pythonz has had a release since 2016. So I'm not sure
pythonz
can be considered as still supported, even if they are merging fixes.I don't really know what to do here. If
pythonz-bd
is maintained, the fix can go in there. If it's not, then personally, I think we should simply droppew install
rather than trying to somehow maintain a patched version of the patched version of the original. But that's easy for me to say as the feature isn't of any use to me. We should see what the other maintainers think.
I also think that pew install
functionality should be removed from Pew.
As a matter of fact, I removed the Python version management functionality in the Fedora Pew package more than 4 years ago and nobody complained.
@tjanez
Some info about our current internal usage in my company.
We are currently using pythonz directly to install python versions by installing it using the installation guide: https://github.com/saghul/pythonz#installation
But we are still using pew[pythonz] because we rely on locate_python
at venv creationg time.
We are open to move to other tools if needed, my goal is to explain that, there might be a third possibility where we keep locate_python
and list_pythons
command and drop install
and uninstall
commands.
I have forked pythonz-bd as it does not work when python minor version have more than one digit.