kpi-web-guild / django-girls-blog-OlenaEfymenko

django-girls-blog-OlenaEfymenko created by GitHub Classroom
MIT License
1 stars 0 forks source link

Configure pyenv #10

Closed webknjaz closed 1 year ago

webknjaz commented 1 year ago
OlenaYefymenko commented 1 year ago

Hello, Sviatoslav I am following manual on Real Python by installing pyenv. Already, pyenv was installed. I am testing changes, could you clarify why I can't execute command: python -m test. This is recommendation from RP:

A great way to get peace of mind that the version of Python you just installed is working properly is to run the built-in test suite

I obtain this result: /home/olenayefymenko/.pyenv/shims/python: No module named test.

I tried to solve this problem by installing: sudo snap install test-python-snap --beta I haven't found an answer yet. As for pyenv I set different variants of the versions, last:

pyenv versions
  system
* 3.10.7 (set by /home/olenayefymenko/.python-version)
  3.11.0
  3.11.1
OlenaYefymenko commented 1 year ago

UPD I understood the idea with test. Installed pytest and executed recommended script.

webknjaz commented 1 year ago

could you clarify why I can't execute command: python -m test. This is recommendation from RP:

A great way to get peace of mind that the version of Python you just installed is working properly is to run the built-in test suite

I obtain this result: /home/olenayefymenko/.pyenv/shims/python: No module named test.

I haven't used that one before. Maybe it isn't bundled anymore.

I tried to solve this problem by installing: sudo snap install test-python-snap --beta

Don't use snap. It's an additional package manager to dnf so I wouldn't mix them up. Besides the locations it manages are completely separate from the ones pyenv sets up. Even if snap installs something, that would be bound to its own copy of Python probably, not pyenv. Also, I don't know what the said package is.

I haven't found an answer yet. As for pyenv I set different variants of the versions, last:

pyenv versions
  system
* 3.10.7 (set by /home/olenayefymenko/.python-version)
  3.11.0
  3.11.1

That's good, I'd switch global to 3.11, though. Also, you've added a local config to the whole home dir. Remove ~/.python-version, it's supposed to be per-project dir, not global. Besides, you'll probably need to create a virtualenv for the project first and use it, not an unisolated interpreter.

webknjaz commented 1 year ago

UPD\nI understood the idea with test. Installed pytest and executed recommended script.

That doesn't sound right. Pytest is a test runner that is normally used for project testing. The paragraph you cited implies testing CPython itself. I hope you didn't install it into the Python's global site-packages? Dists from PyPI should go to virtualenvs, keeping the shared one clean. If you didn't, maybe reinstall that interpreter to clean that up.

FWIW, you don't really need to run CPython tests.

OlenaYefymenko commented 1 year ago

That doesn't sound right. Pytest is a test runner that is normally used for project testing. The paragraph you cited implies testing CPython itself. I hope you didn't install it into the Python's global site-packages? Dists from PyPI should go to virtualenvs, keeping the shared one clean. If you didn't, maybe reinstall that interpreter to clean that up.

I doubt that I understood correctly, especially about CPython's testing itself (I'll probably try to figure it out later). Earlier, I installed Pytest due to dnf in global system (not due pip). Then it was deleted. So, I know that Pytest are used specifically for projects. Unfortunately, firstly I executed it, then thought about its sense

That's good, I'd switch global to 3.11, though. Also, you've added a local config to the whole home dir. Remove ~/.python-version, it's supposed to be per-project dir, not global. Besides, you'll probably need to create a virtualenv for the project first and use it, not an unisolated interpreter.

Thank you, I am practicing, but have some problems/questions, need to learn more attentively

webknjaz commented 1 year ago

It sounds like this task might be ready for now.

OlenaYefymenko commented 1 year ago

Basically, it became clearer. I'd like to clarify with you, the 3 ways for modifying Python versions (via pyenv), depicted the pyramid in the manual RP. Accordingly, we should use global command for home user, local command for directory - our project and shell (for example for several shells, which we have)?

As for my testing in CLI, finally, I set this variant:

pyenv versions     
  system
  3.10.10
* 3.11.1 (set by /home/olenayefymenko/.pyenv/version)
  3.11.1/envs/myproject
  3.11.2
  myproject
webknjaz commented 1 year ago

"global" is not for the user. It's not bound to the dirs. It's just the default/fallback in the shell/zsh session when nothing else overrides it. "local" is picked up from a file .python-version if it's present in the directory layout. And "shell" is used for switching the version for one-time experiments, it's not saved anywhere, if you open a new shell/tab, it won't be there. Also, you can --unset it to revert to the regular behavior based on the global+local settings. Note, that programs invoked by name are looked up through the $PATH env var but if you use the full path to those programs, it'll bypass this magic switching.

OlenaYefymenko commented 1 year ago

Ok, I understand, thanks.

OlenaYefymenko commented 1 year ago

Note, that programs invoked by name are looked up through the $PATH env var but if you use the full path to those programs, it'll bypass this magic switching.

Do you mean this expression in the configuration files? export PATH="$PYENV_ROOT/bin:$PATH"

webknjaz commented 1 year ago

Yes.