I never
used virtual environments and wouldn't like to start with it.
There's your problem - everything else is a result of this. There is
just no nice way to work with a combination of pypi, apt-get and
system-wide python.
Everyone uses virtual environments.
Everyone uses virtual environments.
It is nothing bad about using virtual environments but also not about
not using them. In my own work I haven't see a use case where I needed
them. And I expect that some day I'll encounter a use case for it. This
here is not about pro and cons of virtual environments.
Please explain how the two problems I explained are influenced by not
using virtual environments.
It is nothing bad about using virtual environments but also not aboutYou are in a use case where you need them, right now :) When you
not using them. In my own work I haven't see a use case where I needed
them. And I expect that some day I'll encounter a use case for it. This
here is not about pro and cons of virtual environments.
understand the benefits of virtual environments you will understand what
I meant by that.
Please explain how the two problems I explained are influenced by not
using virtual environments.
The first problem can be avoided because virtual environments can use a different version of python than the system one. If you need an earlier version of python then you can use it instead.
The second problem can be avoided because virtual environments exist in
a part of the file system that you have write access to, so you don't
need to use sudo to install packages. Your main user account does not
have write access to /usr/bin.
Also when a virtual environment is activated the path to it's packages
is a part of that environment so your code will always be able to import
the packages you want.
It's much easier to understand if you try it for yourself. Google has
many excellent resources, here is one https://www.freecodecamp.org/news/how-to-setup-virtual-environments-in-python/
Best of luck :)
R
The first problem can be avoided because virtual environments can use
a different version of python than the system one. If you need an
earlier version of python then you can use it instead.
The second problem can be avoided because virtual environments exist
in a part of the file system
I tried to install it via "pipx install -e .[develop]". It's pyproject.toml has a bug: A missing dependency "dateutil". But "dateutil" is not available from PyPi for Python 3.11 (the default in Debian 12). But thanks to great Debian they have a "python3-dateutil" package. I installed it.
On 2023-09-15 14:15:23 +0000, c.buhtz--- via Python-list wrote:
I tried to install it via "pipx install -e .[develop]". It's pyproject.toml >> has a bug: A missing dependency "dateutil". But "dateutil" is not available >> from PyPi for Python 3.11 (the default in Debian 12). But thanks to great
Debian they have a "python3-dateutil" package. I installed it.
Sidenote:
PyPI does have several packages with "dateutil" in their name. From the version number (2.8.2) I guess that "python-dateutil" is the one
packaged in Debian 12.
This can be installed via pip:
On 2023-09-18 10:16 "Peter J. Holzer via Python-list" <python-list@python.org> wrote:
On 2023-09-15 14:15:23 +0000, c.buhtz--- via Python-list wrote:
I tried to install it via "pipx install -e .[develop]". It's
pyproject.toml has a bug: A missing dependency "dateutil". But
"dateutil" is not available from PyPi for Python 3.11 (the default
in Debian 12). But thanks to great Debian they have a
"python3-dateutil" package. I installed it.
This can be installed via pip:
I'm aware of this. But this is not the question.
I would like to know and understand why my via "pipx" installed package "hyperorg" is not able to see the systems packages installed via "apt
install python3-dateutils"?
Is this the usual behavior? Is this correct?
On 2023-09-15 14:15:23 +0000, c.buhtz--- via Python-list wrote:
I tried to install it via "pipx install -e .[develop]". It's
pyproject.toml has a bug: A missing dependency "dateutil". But
"dateutil" is not available from PyPi for Python 3.11 (the default
in Debian 12). But thanks to great Debian they have a
"python3-dateutil" package. I installed it.
This can be installed via pip:
On 2023-09-18 10:16 "Peter J. Holzer via Python-list" <python-list@python.org> wrote:
On 2023-09-15 14:15:23 +0000, c.buhtz--- via Python-list wrote:
I tried to install it via "pipx install -e .[develop]". It's
pyproject.toml has a bug: A missing dependency "dateutil". But
"dateutil" is not available from PyPi for Python 3.11 (the default
in Debian 12). But thanks to great Debian they have a
"python3-dateutil" package. I installed it.
This can be installed via pip:
I'm aware of this. But this is not the question.
I would like to know and understand why my via "pipx" installed package "hyperorg" is not able to see the systems packages installed via "apt
install python3-dateutils"?
Is this the usual behavior? Is this correct?
What is the design decision behind it?
Is it really the intention of PEP668 that pipx-installed packages are
not allowed to use system packages?
On 2023-09-18 10:16 "Peter J. Holzer via Python-list" <python-list@python.org> wrote:
On 2023-09-15 14:15:23 +0000, c.buhtz--- via Python-list wrote:
I tried to install it via "pipx install -e .[develop]". It's pyproject.toml has a bug: A missing dependency "dateutil". But
"dateutil" is not available from PyPi for Python 3.11 (the default
in Debian 12). But thanks to great Debian they have a
"python3-dateutil" package. I installed it.
This can be installed via pip:
I'm aware of this.
"dateutil" is not available from PyPi for Python 3.11
But this is not the question.
"dateutil" is not available from PyPi for Python 3.11
That's quite a curious thing to write if you are aware that dateutil is
in fact available from PyPi for Python 3.11.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 60:05:56 |
Calls: | 6,712 |
Files: | 12,243 |
Messages: | 5,355,756 |