I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
P.
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version? _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
On Mon, 11 Dec 2017 16:32:06 -0500 Larry Martell wrote:
Can I make that the default python?
~/.bashrc
No. I'm not entirely sure that is a good idea! No, not all.
'scl enable python27 bash' creates a *new* shell with the correct environment. As each invocation of bash reads .bashrc, it will also create another new shell which will then read .bashrc and create another shell ....
Depending on the speed of your machine and disks and how much memory you have, it will take a few seconds to a few minutes to grind your machine to a halt.
P.
Pete Biggs wrote:
On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
On Mon, 11 Dec 2017 16:32:06 -0500 Larry Martell wrote:
Can I make that the default python?
~/.bashrc
No. I'm not entirely sure that is a good idea! No, not all.
'scl enable python27 bash' creates a *new* shell with the correct environment. As each invocation of bash reads .bashrc, it will also create another new shell which will then read .bashrc and create another shell ....
Depending on the speed of your machine and disks and how much memory you have, it will take a few seconds to a few minutes to grind your machine to a halt.
The simplest way is to . <path/to/python2.7/enable, and you're good to go.
mark
On Tue, Dec 12, 2017 at 11:31 AM, m.roth@5-cent.us wrote:
Pete Biggs wrote:
On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
On Mon, 11 Dec 2017 16:32:06 -0500 Larry Martell wrote:
Can I make that the default python?
~/.bashrc
No. I'm not entirely sure that is a good idea! No, not all.
'scl enable python27 bash' creates a *new* shell with the correct environment. As each invocation of bash reads .bashrc, it will also create another new shell which will then read .bashrc and create another shell ....
Depending on the speed of your machine and disks and how much memory you have, it will take a few seconds to a few minutes to grind your machine to a halt.
The simplest way is to . <path/to/python2.7/enable, and you're good to go.
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I definitely wouldn't make it the default python, but I have made it the default for a particular user as long as they are not root.
In the past I have got python27-mod_wsgi and httpd24-httpd working together by doing things like httpd24-httpd by doing things like
cat /opt/rh/httpd24/root/etc/sysconfig/httpd
export PATH=/opt/rh/python27/root/usr/bin:$PATH export LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
On Mon, Dec 11, 2017 at 5:43 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 11:31 AM, m.roth@5-cent.us wrote:
Pete Biggs wrote:
On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
On Mon, 11 Dec 2017 16:32:06 -0500 Larry Martell wrote:
Can I make that the default python?
~/.bashrc
No. I'm not entirely sure that is a good idea! No, not all.
'scl enable python27 bash' creates a *new* shell with the correct environment. As each invocation of bash reads .bashrc, it will also create another new shell which will then read .bashrc and create another shell ....
Depending on the speed of your machine and disks and how much memory you have, it will take a few seconds to a few minutes to grind your machine to a halt.
The simplest way is to . <path/to/python2.7/enable, and you're good to go.
I definitely wouldn't make it the default python, but I have made it the default for a particular user as long as they are not root.
In the past I have got python27-mod_wsgi and httpd24-httpd working together by doing things like httpd24-httpd by doing things like
cat /opt/rh/httpd24/root/etc/sysconfig/httpd
export PATH=/opt/rh/python27/root/usr/bin:$PATH export LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
I am running nginx and uWSGI. I added this to /etc/systemd/system/uwsgi.service:
ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor /etc/uwsgi/sites
But it did not start:
Loaded: loaded (/etc/systemd/system/uwsgi.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since Mon 2017-12-11 17:20:36 EST; 6s ago Process: 24492 ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor /etc/uwsgi/sites (code=exited, status=1/FAILURE)
On 12/11/2017 2:50 PM, Larry Martell wrote:
ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor /etc/uwsgi/sites
You probably want:
ExecStart=/usr/bin/scl enable python27 '/usr/bin/uwsgi --emperor /etc/uwsgi/sites'
See:
On Mon, Dec 11, 2017 at 5:57 PM, Kenneth Porter shiva@sewingwitch.com wrote:
On 12/11/2017 2:50 PM, Larry Martell wrote:
ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor /etc/uwsgi/sites
You probably want:
ExecStart=/usr/bin/scl enable python27 '/usr/bin/uwsgi --emperor /etc/uwsgi/sites'
See:
With that change it starts, but still with 2.7.5:
*** Starting uWSGI 2.0.13.1 (64bit) on [Mon Dec 11 17:47:19 2017] *** compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 28 July 2016 12:32:18 os: Linux-3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 nodename: padev machine: x86_64 clock source: unix detected number of CPU cores: 8 current working directory: /etc/uwsgi/sites detected binary path: /usr/bin/uwsgi chdir() to /usr/local/motor/motor your processes number limit is 195775 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to UNIX address /usr/local/motor/motor.sock fd 3 Python version: 2.7.5 (default, Sep 15 2016, 22:37:39) [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] *** Python threads support is disabled. You can enable it with --enable-threads *** Python main interpreter initialized at 0x13a75e0 your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 1115752 bytes (1089 KB) for 10 cores *** Operational MODE: preforking *** WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x13a75e0 pid: 25616 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 25616) spawned uWSGI worker 1 (pid: 25693, cores: 1) spawned uWSGI worker 2 (pid: 25694, cores: 1) spawned uWSGI worker 3 (pid: 25695, cores: 1) spawned uWSGI worker 4 (pid: 25696, cores: 1) spawned uWSGI worker 5 (pid: 25697, cores: 1) spawned uWSGI worker 6 (pid: 25699, cores: 1) spawned uWSGI worker 7 (pid: 25700, cores: 1) spawned uWSGI worker 8 (pid: 25701, cores: 1) spawned uWSGI worker 9 (pid: 25702, cores: 1) spawned uWSGI worker 10 (pid: 25703, cores: 1)
On 12/11/2017 1:32 PM, Larry Martell wrote:
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
The "default" python is a dependency for many other system packages, so changing it without understanding what effect it will have on other parts of the system would be dangerous. The idea behind Software Collections is that you only affect the packages that truly need the newer version.
How are you launching django and uWSGI? I'd suggest putting the SC command in their startup scripts to keep the new version confined to them.
On 12/11/2017 03:32 PM, Larry Martell wrote:
On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
You likely can not make it the default python .. because all the system based things will likely break.
However, you CAN add (call) the correct environment to your startup scripts for the proper deamons in init, which should run the required servers with the version of python that you want.
The whole purpose of SCLs is to allow multiple versions of the same items to run together on a given machine, and you can pick the one you need for a give application/server service .. WHILE, not breaking 9in the case of python) things like yum :).
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
I believe doing something like
source scl_source enable python27
in .bashrc will do that. But the scl_source command is a fairly recent addition so hopefully you have it. See:
https://access.redhat.com/solutions/527703
Try it from a command line first before committing it to your .bashrc
There are some things on the web about using django and uWSGI with software collections. For instance:
https://developers.redhat.com/blog/tag/django/
but I know nothing about any of the applications so I don't know how relevant this is.
P.
On Mon, Dec 11, 2017 at 4:32 PM, Larry Martell larry.martell@gmail.com wrote:
On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
Or use Software Collections, the Python27 package from there has 2.7.13
https://www.softwarecollections.org/en/scls/rhscl/python27/
https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
After I issue the command scl enable python27 bash, and my python is then 2.7.13, when I run pip will it use 2.17.13 to build what I am downloading?
Larry Martell wrote:
On Mon, Dec 11, 2017 at 4:32 PM, Larry Martell larry.martell@gmail.com wrote:
On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
On 05.12.2017 14:05, Larry Martell wrote: > I am running CentOS 7 and I have python version: > Python 2.7.5 (default, Sep 15 2016, 22:37:39) > I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
<snip>
Or use Software Collections, the Python27 package from there has 2.7.13 https://www.softwarecollections.org/en/scls/rhscl/python27/ https://wiki.centos.org/AdditionalResources/Repositories/SCL
I followed the instructions at the first link and I still only seem to have 2.7.5. How can I specify a newer version?
Hi, perhaps reading https://www.softwarecollections.org/en/ and https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
Have you done scl enable python27 bash in your current shell?
Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I want django and uWSGI to use that version.
<snip> I guess my very brief suggestion wasn't understood: in whatever shell script you use to start the tools you want to use, insert, at the top, right under the #!/bin/bash, the line . /opt/<path/to/python2.7>/enable so that the paths are set for that shell script, and all its children. This will not result in you going into python's command line, nor will it affect anything else, including yum.
mark
On Tue, Dec 12, 2017 at 9:11 AM, m.roth@5-cent.us wrote:
Larry Martell wrote:
On Mon, Dec 11, 2017 at 4:32 PM, Larry Martell larry.martell@gmail.com wrote:
On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks clintd@scms.waikato.ac.nz wrote:
On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell larry.martell@gmail.com wrote:
On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote: > On 05.12.2017 14:05, Larry Martell wrote: > > I am running CentOS 7 and I have python version: > > Python 2.7.5 (default, Sep 15 2016, 22:37:39) > > I need a newer version of 2.7 to pick up a bug fix. How can I do > that (without breaking anything in CentOS)?
<snip> >>>> > Or use Software Collections, the Python27 package from there has >>>> > 2.7.13 >>>> > https://www.softwarecollections.org/en/scls/rhscl/python27/ >>>> > https://wiki.centos.org/AdditionalResources/Repositories/SCL >>>> >>>> I followed the instructions at the first link and I still only seem to >>>> have 2.7.5. How can I specify a newer version? >> >>> Hi, perhaps reading https://www.softwarecollections.org/en/ and >>> https://www.softwarecollections.org/en/scls/rhscl/python27/ will help. >>> >>> Have you done scl enable python27 bash in your current shell? >> >> Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type >> that command in each new shell. Can I make that the default python? I >> want django and uWSGI to use that version. <snip> I guess my very brief suggestion wasn't understood: in whatever shell script you use to start the tools you want to use, insert, at the top, right under the #!/bin/bash, the line . /opt/<path/to/python2.7>/enable so that the paths are set for that shell script, and all its children. This will not result in you going into python's command line, nor will it affect anything else, including yum.
Sorry, missed your previous post. Ended up that I had to reinstall uWSGI using the 2.5.13 pip, and then link /opt/rh/python27/root/usr/bin/uwsgi to /usr/bin/uwsgi. Now that I have it running, hopefull it will resolve the issue I had (which was a bug in the 2.7.5 zlib).
On Tue, Dec 5, 2017 at 8:16 AM, Kai Grunau kgrunau@geomar.de wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
I am not familiar with that. This is for a django app, using nginx, uWSGI, and mysql - will it integrate easily with those components?
On 05.12.2017 14:24, Larry Martell wrote:
On Tue, Dec 5, 2017 at 8:16 AM, Kai Grunau kgrunau@geomar.de wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
I am not familiar with that. This is for a django app, using nginx, uWSGI, and mysql - will it integrate easily with those components?
Anaconda is a python installation independent of the OS. You can install it without root rights. Only your environment has to change to use the new python version
I think is easy to work with those components
On 12/05/2017 02:45 PM, Kai Grunau wrote:
On 05.12.2017 14:24, Larry Martell wrote:
On Tue, Dec 5, 2017 at 8:16 AM, Kai Grunau kgrunau@geomar.de wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
I am not familiar with that. This is for a django app, using nginx, uWSGI, and mysql - will it integrate easily with those components?
Anaconda is a python installation independent of the OS. You can install it without root rights. Only your environment has to change to use the new python version
I think is easy to work with those components
I've happily been using python virtual environments (similar to anaconda) alongside with Apache, WSGI & django for a long time. The setup using NGINX should be almost the same (with some small differences in setting up NGINX, of course).
I would suggest "virtualenv" instead of anaconda: The principle is the same, but it offers just a bit more flexibility and customization. Virtualenv creates a local (non-system) installation of python, and you can create different collections of packages stored as different environments. In this way you can have multiple versions of python + different collections of packages all living happily side by side on the same machine.
Regarding the setup with uWSGI + NGINX, the Django documentation "How to use Django with Apache and mod_wsgi" is excellent: https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/
There is also a similar setup for NGINX on readthedocs (which I assume will also work): http://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html
For the rest: Google is your friend, you'll find lots of information on each of these topics.
Good luck!
Marc
On Tue, Dec 5, 2017 at 10:00 AM, Marc Gouw marc.gouw@embl.de wrote:
On 12/05/2017 02:45 PM, Kai Grunau wrote:
On 05.12.2017 14:24, Larry Martell wrote:
On Tue, Dec 5, 2017 at 8:16 AM, Kai Grunau kgrunau@geomar.de wrote:
On 05.12.2017 14:05, Larry Martell wrote:
I am running CentOS 7 and I have python version:
Python 2.7.5 (default, Sep 15 2016, 22:37:39)
I need a newer version of 2.7 to pick up a bug fix. How can I do that (without breaking anything in CentOS)?
you could use the anaconda software, it is independent of the OS regards
I am not familiar with that. This is for a django app, using nginx, uWSGI, and mysql - will it integrate easily with those components?
Anaconda is a python installation independent of the OS. You can install it without root rights. Only your environment has to change to use the new python version
I think is easy to work with those components
I've happily been using python virtual environments (similar to anaconda) alongside with Apache, WSGI & django for a long time. The setup using NGINX should be almost the same (with some small differences in setting up NGINX, of course).
I would suggest "virtualenv" instead of anaconda: The principle is the same, but it offers just a bit more flexibility and customization. Virtualenv creates a local (non-system) installation of python, and you can create different collections of packages stored as different environments. In this way you can have multiple versions of python + different collections of packages all living happily side by side on the same machine.
Regarding the setup with uWSGI + NGINX, the Django documentation "How to use Django with Apache and mod_wsgi" is excellent: https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/
There is also a similar setup for NGINX on readthedocs (which I assume will also work): http://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html
For the rest: Google is your friend, you'll find lots of information on each of these topics.
This is a very mature app that we have deployed in many sites. The older sites run CentOS 6 and use apache and modwsgi. The newer sites run CentOS 7 and use nginx and uWSGI. So we am very familiar with their respective setups. But I have never used anything other then the out of the box python that came with the OS. So I am not sure how to get that nor if it will break anything. I am going to investigate Pete Biggs' suggestion to use Software Collections.
-
Andrew Holway -
Clint Dilks -
Frank Cox -
Johnny Hughes -
Kai Grunau -
Kenneth Porter -
Larry Martell -
m.roth＠5-cent.us -
Marc Gouw -
Pete Biggs