3 minutes ago, sansi98 said:

I'm not sure where this Python came from; maybe it was pre-installed with the system?

surely not.

look elsewhere

 

Just now, MAM59 said:

surely not.

look elsewhere

 

 

It could be part of the iSCSI plugin too, I think.

25 minutes ago, Rysz said:

 

It could be part of the iSCSI plugin too, I think.

I did install the iSCSI plugin for Unraid Server plugin

 

So I can't use the plug-in? But I don't want to uninstall the iSCSI plugin and Re-install it

 

1 hour ago, sansi98 said:

I did install the iSCSI plugin for Unraid Server plugin

 

So I can't use the plug-in? But I don't want to uninstall the iSCSI plugin and Re-install it

 

 

I'd recommend not to use my plugin then, as installing multiple versions of Python may introduce problems on an OS that is not primarily intended for such applications. Ideally you should use the version bundled with that plugin for your Python needs, or switch to alternatives using Docker containers or VMs.

3 hours ago, sansi98 said:

I'm not sure where this Python came from; maybe it was pre-installed with the system?

iSCSI-Target ships with a custom version from Python since it is needed to run targetcli and other related binaries. It includes also necessary packages which are not part of the default Python package (configshell-fb, rtslib-fb,...).

1 hour ago, ich777 said:

iSCSI-Target ships with a custom version from Python

MAYBE you should think about dropping this version (and pointing to the new plugin instead), OR rework it so it uses a private virtual version?

 

It is not really a good idea to have 2 things doing the same and blocking each other.

 

And its enough that one implementation keeps an eye on updates and so on.

 

As I cannot see any direct connection between ISCSI (besides it depends partly on python) and python itself, I would recommend to delete it from ISCSI and tell the users that for fully operationalbilty they should also install the Python Plugin.

 

5 minutes ago, MAM59 said:

MAYBE you should think about dropping this version (and pointing to the new plugin instead), OR rework it so it uses a private virtual version?

 

It is not really a good idea to have 2 things doing the same and blocking each other.

 

And its enough that one implementation keeps an eye on updates and so on.

 

As I cannot see any direct connection between ISCSI (besides it depends partly on python) and python itself, I would recommend to delete it from ISCSI and tell the users that for fully operationalbilty they should also install the Python Plugin.

 

 

Well, to be fair, @ich777 explained in the post above yours that iSCSI requires special packages (which I won't be shipping for all users).

It's not really blocking anything either, the point of this plugin is to be able to use Python at all, and you can use Python with iSCSI also... 🙂 

1 minute ago, Rysz said:

It's not really blocking anything either, the point of this plugin is to be able to use Python at all, and you can use Python with iSCSI also...

yeah, but I am thinking a few months/years ahead. When versions increase and updates are needed. Its better to have a single point to think of...

 

And, as we can see from the current problem here, no normal person is aware about the coupling now ( I wasn't either, which does not mean a thing, but can be taken as a symptom).

So there will be more complains  like this. Takes time, needs clearup, some people will become angry or so. Not needed.

 

And having two people working on the same thing (updates) isn't really helpful either. Just a waste of time.

 

Docker are already evil, but a least they seperate their environments from the others. So less interference happens.

 

Plugins should be the same and focus on their single use, not combining stuff that does not directly belong to them.

 

36 minutes ago, MAM59 said:

MAYBE you should think about dropping this version (and pointing to the new plugin instead), OR rework it so it uses a private virtual version?

In my opinion, as I said many times on the forums here, Unraid is not a general purpose server, it is a application server and no one should ever run Python directly on Unraid itself except if a plugin needs Python (targetcli-fb needs it yes).

 

21 minutes ago, MAM59 said:

Docker are already evil, but a least they seperate their environments from the others. So less interference happens.

You could also use LXC since this behaves more like a VM with persistent storage and would be my preferred way to install Python on Unraid if someone really needs it.

 

Again, as said above, it is really hard to maintain a plugin (iSCSI-Target-Plugin) that relies on another plugin (Python3-Plugin) where the packages which are needef for iSCSI-Target (targetcli-fb, rtslib-fb,...) need to be recompiled each time the Python3-Plugin gets updated and this will cause more trouble than like it's currently implemented (EDIT: Not to mention I saw that @Rysz also has multiple versions available and that would be way harder to support).

You have to also take into consideration that you then have to make users aware that you have to install Python3 if you install iSCSI and if one doesn't do that it won't work and cause additional support requests.

 

The package that ships with iSCSI is nothing special and updated when a major version change happened and was not necessary to date since everything is working (this is the first request about that to date, at least that I can remember of).

 

However, if you really want to put the time and effort into converting the Python3 package that ships with iSCSI into a private package no one is stopping you from doing so, I'm happy to accept PRs on GitHub.

2 minutes ago, ich777 said:

You could also use LXC since this behaves more like a VM a

To make it clear: I don't use any of these plugins myself. I once had the need for python, but that is gone already.

 

I am just talking about how to keep a system clean and without interferences like it happened now here.

And how to avoid to confuse users.

 

It would be no big deal to tell your "customers" that they need to install python from another source. And I guess, nobody would complain.

 

Its the same like things as nextcloud for instance, that need a additional database to be installed.

 

But then, its your desicion... just my 25cts...

 

32 minutes ago, MAM59 said:

So there will be more complains  like this. Takes time, needs clearup, some people will become angry or so. Not needed.

 

I don't really see the potential for complaints here, and some people will always be angry. It's just a choice users will have to make, as with everything in life. It's like choosing if you want iOS or Android, can't have everything at the same time. I don't have 100% the same opinion about Python on Unraid as @ich777 has, but I also think that it should not be used for intensive things and rather help with very specific file-storage related tasks (the less, the better). The reason I made this plugin is because users honestly came up with stupid and outright dangerous solutions to install Python on Unraid, so this provides a safe and low maintenance alternative for that (even offering various versions just so everyone can be satisfied). "Safe" is checking against double package installation.

 

8 minutes ago, MAM59 said:

I am just talking about how to keep a system clean and without interferences like it happened now here.

And how to avoid to confuse users.

 

How is preventing a double package installation not keeping the system clean or without interference? It's doing just that... iSCSI needs specific packages that this plugin can and will not provide (for various reasons). I have no interest taking into consideration iSCSI during the development of this plugin (as I'm sure @ich777 has no special interest in this plugin's direction either), so the respectful solution from my side was to not overestimate the importance of my own plugin and put in the appropriate safeguard so it does not mess with the stability of user's systems e.g. by installing on top of an existing Python installation.

 

53 minutes ago, Rysz said:

iSCSI needs specific packages that this plugin can and will not provide (for various reasons). I have no interest taking into consideration iSCSI during the development of this plugin (as I'm sure @ich777 has no special interest in this plugin's direction either),

Ok, I see, either I need to rephrase (see my disclaimer) or both of you do not really know how to handle python...

 

What I mean:

* YOU should supply python with your plugin

*  @ich777 should delete it from his plugin

 

Yeah, now he says, he needs special modules to be installed for running his application, this shows that you don't know how python works...

* there is no difference between a local program and a module!

you can simply download the "module" and copy the *.py file into the directory of the application (where his *.py scripts are located). Local files are looked up and used first, then the local module store ("virtual environment") is checked. last are "global" modules checked.

So if you "pip install <module>" it just download that module and store it in a certain folder. Copy it out into the program's directory and you are done, no need for "pip" anymore!

(of course, if these modules need updates, you have to reload and copy them over manually, but this does not happen very often...)

 

So it is really easy to do a "clean" shipment of "pure" python and "application with modules".

 

Hi, i upgraded from 6.12.10 to 6.12.14 and had python3 installed with old nerdtools, but now wanted to using this pluging to support it going forward.

But i got into a first hurdle here. error message "ERROR: Could not find a version that satisfies the requirement time (from versions: none)" when trying to use pip install OS, time, platform etc.

 

Any pointers to what im doing wrong?

3 minutes ago, orlando500 said:

Hi, i upgraded from 6.12.10 to 6.12.14 and had python3 installed with old nerdtools, but now wanted to using this pluging to support it going forward.

But i got into a first hurdle here. error message "ERROR: Could not find a version that satisfies the requirement time (from versions: none)" when trying to use pip install OS, time, platform etc.

 

Any pointers to what im doing wrong?

 

The modules you listed are in-built with Python, you can't install them with "pip" - hence the error message.

 

14 minutes ago, Rysz said:

 

The modules you listed are in-built with Python, you can't install them with "pip" - hence the error message.

 

ah thanks. i think i just had a small mental breakdown when the upgrade broke my python3 install  and just didnt think... 🙂

Hello,

When I installed I get these errors:

plugin: skipping: python3-3.13.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.12.7-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.11.10-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99

 

How to fix it ?

25 minutes ago, pbear said:

Hello,

When I installed I get these errors:

plugin: skipping: python3-3.13.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-2dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.12.7-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-1dwl_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 plugin: skipping: python3-3.11.10-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-pip-24.2-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99 
plugin: skipping: python-setuptools-75.1.0-x86_64-1dw_slack15.0.txz - Unraid version too high, requires at most version 6.12.99

 

How to fix it ?

 

If you read a few lines above you'll see:

Quote

echo "-------------------------------------------------------------"
echo " !!! INSTALLING, THIS MAY TAKE A WHILE..."
echo " !!! IT IS NORMAL THAT SOME PACKAGES ARE SKIPPED"
echo " !!! KEEP THIS WINDOW OPEN UNTIL COMPLETION IS REPORTED"
echo "-------------------------------------------------------------"
echo ""

So it's normal and there's nothing to fix.

 

I am for sure messing this up but I tried to run the command "pip install screen" and got this error below:

 

Quote

Collecting screen
  Downloading screen-1.0.1.tar.gz (8.6 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: screen
  Building wheel for screen (pyproject.toml) ... error
  error: subprocess-exited-with-error
 
  × Building wheel for screen (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [29 lines of output]
      running bdist_wheel
      The [wheel] section is deprecated. Use [bdist_wheel] instead.
      /tmp/pip-build-env-mktnks6v/overlay/lib/python3.11/site-packages/setuptools/_distutils/cmd.py:124: SetuptoolsDeprecationWarning: bdist_wheel.universal is deprecated
      !!
      
              ********************************************************************************
              With Python 2.7 end-of-life, support for building universal wheels
              (i.e., wheels that support both Python 2 and Python 3)
              is being obviated.
              Please discontinue using this option, or if you still need it,
              file an issue with pypa/setuptools describing your use case.
      
              By 2025-Aug-30, you need to update your project and remove deprecated calls
              or your builds will no longer be supported.
              ********************************************************************************
      
      !!
        self.finalize_options()
      running build
      running build_py
      creating build/lib.linux-x86_64-cpython-311/screen
      copying screen/__init__.py -> build/lib.linux-x86_64-cpython-311/screen
      copying screen/compat.py -> build/lib.linux-x86_64-cpython-311/screen
      copying screen/old_str_util.py -> build/lib.linux-x86_64-cpython-311/screen
      running build_ext
      building 'screen.str_util' extension
      creating build/temp.linux-x86_64-cpython-311/source
      gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/include/python3.11 -c source/str_util.c -o build/temp.linux-x86_64-cpython-311/source/str_util.o
      error: command 'gcc' failed: No such file or directory
      [end of output]
 
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for screen
Failed to build screen
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (screen)

 

you may also need to 3rd party install screen. For your use case. Missing libs/application that python screen calls that host unraid doesn't have.

https://slackware.pkgs.org/15.0/slackware-x86_64/screen-4.9.0-x86_64-1.txz.html

 

cd /boot/extras
wget https://slackware.uk/slackware/slackware64-15.0/slackware64/ap/screen-4.9.0-x86_64-1.txz

reboot to install...

 

I think you need to call a path and have a venv setup first then source activate then call pip install.

 

as <unraid ip>/Settings/dwpython

Quote

This plugin aims to provide a simple and functional python3 installation, including pip and setuptools for any package needs.
Since Python is rather invasive on the system, all global package installations themselves are only kept in RAM and it is possible to easily revert any brokenness by rebooting the system.
If, after any reboots, you do not want to manually re-install any such global packages that you might need, you can put any pip commands in the provided autoexec.sh file using the editor.

 

and in script area:

Quote

#
# Put here all commands that you wish to to execute after a system reboot.
# They are executed NON-BLOCKING (but sequentially), ensuring the boot sequence proceeds regardless of any script error.
#
# The purpose of this script, for example, is to establish that certain global packages are always installed with `pip`.
# Please keep in mind that using virtual environments is always preferable over globally installing any Python packages.
#
# All output is directed to the SYSLOG. To prevent this, append ` &>/dev/null` (without quotes) to the end of any command.
# Alternatively, just put `exec &>/dev/null` on the first non-comment line of this script to disable ALL commands outputs

 

my recommendation is make a venv environment.

 

Chose a path in my case I have a share called cloud so I placed my venv there...
 

so I cd into the location

One TIME - First time install a VENV

python3 -m venv unraid

then to activate and use the venv:

I cd into the path and activate unraid python

Example:

#Start of script
cd /mnt/user/Cloud
#Activate the virtual environment
source unraid/bin/activate

#Python comands like pip install or python3 -m pip install .... etc etc

#close venv
deactivate
exit 0

 

Edited January 10, 20251 yr by bmartino1
typo

5 hours ago, remati said:

I am for sure messing this up but I tried to run the command "pip install screen" and got this error below:

 

 

 

This will try to build screen on the Unraid system, likely fails due to unmet build dependencies.

As @bmartino1 pointed out, you'd need a pre-compiled package to use it "out of the box". 🙂 

 

Otherwise I can recommend to check out my new plugin:

"Tmux Terminal Manager (TTM)" which lets you create persistent terminals from the GUI.

And it also provides tmux for command-line use, which is a more featureful alternative to screen.

https://forums.unraid.net/topic/183427-plugin-tmux-terminal-manager-ttm/

 

After upgrading to UnRAID 7.0.1 on both my servers I'm struggling that the WebUI becomes unresponsive on one of them (with 14700k/w680 motherboard). It just dies completely. Trying to run "htop" from SSH also crashes while the terminal/shares/docker seems to continue to work. The only thing that I can find in the logs is this being logged multiple times over:
 

[ 2663.825421] python3[537547]: segfault at 6 ip 0000152dc136e9f1 sp 0000152db6db2d20 error 6 in libpython3.11.so.1.0[152dc126c000+1d4000] likely on CPU 12 (core 24, socket 0)
[ 2663.825429] Code: 7e 3f 49 8b 7e 18 48 85 ff 74 0a 48 83 2f 01 0f 84 30 03 00 00 48 83 7b 18 04 7e 25 b8 04 00 00 00 49 8b 3c c6 48 85 ff 74 0a <48> 83 2f 01 0f 84 1d 03 00 00 48 83 c0 01 48 3b 43 18 7c e3 0f 1f

Are you familiar with this issue? I have two UnRAID servers on 7.0.1 and they use the exactly same plugins/versions (just the hardware is different), but only one of them seems to struggle with this. Is this plugin somehow incompatible with my HW or any idea what may be happening here? I have no Python scripts in "user scripts". I only use Python in order to manage my docker containers (using docker-compose without pip-dependencies) so that's why I would prefer to have it outside of docker if possible.

Edited February 26, 20251 yr by NeoID

8 minutes ago, NeoID said:

After upgrading to UnRAID 7.0.1 on both my servers I'm struggling that the WebUI becomes unresponsive on one of them (with 14700k/w680 motherboard). It just dies completely. Trying to run "htop" from SSH also crashes while the terminal/shares/docker seems to continue to work. The only thing that I can find in the logs is this being logged multiple times over:
 

[ 2663.825421] python3[537547]: segfault at 6 ip 0000152dc136e9f1 sp 0000152db6db2d20 error 6 in libpython3.11.so.1.0[152dc126c000+1d4000] likely on CPU 12 (core 24, socket 0)
[ 2663.825429] Code: 7e 3f 49 8b 7e 18 48 85 ff 74 0a 48 83 2f 01 0f 84 30 03 00 00 48 83 7b 18 04 7e 25 b8 04 00 00 00 49 8b 3c c6 48 85 ff 74 0a <48> 83 2f 01 0f 84 1d 03 00 00 48 83 c0 01 48 3b 43 18 7c e3 0f 1f

Are you familiar with this issue? I have two UnRAID servers on 7.0.1 and they use the exactly same plugins/versions (just the hardware is different), but only one of them seems to struggle with this. Is this plugin somehow incompatible with my HW or any idea what may be happening here? I have no Python scripts in "user scripts", but I have some custom tools for updating Docker containers (docker-compose) so I prefer having Python installed on UnRAID.

 

I'd recommend running an extensive RAM test since a segmentation fault occurs when a program tries to access an invalid memory address. The issue could be with Python mistakenly thinking the address is valid, or with faulty RAM corrupting previously valid memory. Since there aren’t widespread reports of this issue, my first guess would be a problem with your RAM.

 

Unless you are running some programs in Python that are directly working on the memory (C/C++ bindings come to mind...)?

 

Nope, it's only a quite simple Python tool to mange the docker containers, so nothing that would work on the memory directly causing issues like this. I use ECC memory and did take a memory test (maybe not extensive enough?)
 

Edited February 26, 20251 yr by NeoID

7 minutes ago, NeoID said:

Nope, it's only a quite simple Python tool to mange the docker containers, so nothing that would work on the memory directly causing issues like this. I use ECC memory and did take a memory test (maybe not extensive enough?)
 

 

That's interesting, is this an open-source tool (the one managing your Dockers) or something self-written?

7 minutes ago, Rysz said:

 

That's interesting, is this an open-source tool (the one managing your Dockers) or something self-written?

Yes, I wrote it and it's on GitHub:
https://github.com/IDmedia/docker-update-script

Nothing fancy really, just prefer this solution as I migrated to UnRAID already having a docker folder where every service is one directoy. Using this tool I can update one or 100 containers in one go and it only restarts those who has changed. Just a personal preference.

Combining it with a user script like this makes it super handy, as all I have to do "docker-update" and it updates everything. Never had any issues:
 

Quote

 

#!/bin/bash

if ! grep -q "alias docker-update" "/root/.bash_profile"; then
    echo 'alias docker-update="cd /mnt/user/docker/ && python3 update.py"' >> /root/.bash_profile
fi

source /root/.bash_profile

 

I might just remove the Python package and rewrite the alias to run this through docker. Again, I just liked it being able to write a pure-Python script on the host directly when I had to automate something instead of using Bash.