pew-org / pew

A tool to manage multiple virtual environments written in pure python
MIT License
1.17k stars 81 forks source link

Fix "python install" command for python >= 3.10 #238

Closed M0dM closed 10 months ago

M0dM commented 11 months ago

I have forked pythonz-bd as it does not work when python minor version have more than one digit.

M0dM commented 11 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.

pfmoore commented 11 months ago

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.

berdario commented 11 months ago

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.

M0dM commented 11 months ago

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
pfmoore commented 11 months ago

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.

M0dM commented 11 months ago

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 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.

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
tjanez commented 10 months ago

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 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.

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.

M0dM commented 10 months ago

@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.