I don't have many experience in using Linux so I decided to use the Windows Subsystem for Linux.
I find out that I have many package installed in WSL but I didn't installed it. Is this OK?
python package listed
Yes, this is perfectly normal. As you can see by the python3- prefix, all of them come with a standard python3 installation.
For example: python3-pip is used to install other packages and python3-requests is used to make requests to web pages and API endpoints.
I don't see any problems with this list of packages, it looks fine.
Depending on your distro (for example, Ubuntu), Python 3 comes installed by default.
Related
I have a RHEL system which by default was running Python2.7 and Python3.4
I needed Python3.6 for a project I wanted to work on and so I downloaded it and built it from source. I ran make and make install which hindsight may have been the wrong decision.
Now I do not seem to have any internet connectivity. Does anyone know what I may have over written to cause this or at least where specifically I can look to track this issue down?
Note: I can Putty into the Linux machine but it doesn't seem to have any other connectivity, specifically HTTPS
It's a bit weird that this would break network connectivity. One possible explanation is that the system has networking scripts or a network manager that relies on Python, and it got broken after make install replaced your default Python installation. It may be possible to fix this by reinstalling your RHEL Python packages (sorry, cannot offer more detailed help there, as I don't have access to a RHEL box).
I guess the lesson is "be careful about running make install as superuser". To easily install and manage different Python versions (separate from the system Python), the Anaconda Python distribution would be a good solution.
I suggest to undo that 3.6 installation and use the Software Collections version of python 3.6. See here for python 3.6 installation. Software Collections install "along side" the original versions so as to not affect the OS - and they are included in the subscription.
So after a lot of time slamming my head against the wall I got it worked out. My best guess is that the system (RHEL 7) relied on something from its default Python2.7 installation to handle SSL negotiations. Installing 3.6 alongside must have overwritten some pointer. Had I done this correctly, with altinstall all would have likely been fine.
The most frustrating part of this is that there were no error messages, connections just timed out.
To fix this, I had to uninstall all Python versions and then reinstalled Python2.7 - Once Python2 was back in the system it all seemed to work well.
I'm trying to install plone 4.3.4 on a SLES 11 SP3 64bit server via the Unified Installer. I've fullfilled all the dependencies listed in the readme.txt, but when I try to get the installer running with the command sudo ./install.sh --password=******* standalone I get the error message: which: no python2.7 in (/usr/bin:/bin:/usr/sbin:/sbin) Unable to find python2.7 on system exec path.
I find that rather strange as in the description of the unified installer it is said "The new Zope/Plone install will use its own copy of Python, and the Python installed by the Unified Installer will not replace your system's copy of Python. You may optionally use your system (or some other) Python, and the Unified Installer will use it without modifying it or your site libraries." on the Plone-Website.
So - what am I doing wrong???
I've just tried adding the parameter --build-python but had to find out that the libxml2-devel and libxslt-devel libraries that are available for SLES-11-SP-3 are sadly not up-to-date enough 2.7.6 instead of 2.7.8 and 1.1.24 instead of 1.1.26 respectively. So no joy there either. :-(
Is there any way to install the current version of plone on SLES 11 SP3 64bit?
Kate
The installer command:
./install.sh standalone --build-python --static-lxml=yes
worked perfectly for me. The installer downloaded and built the Python and libxml2/libxslt components necessary to remedy the terribly out-of-date (and vulnerable) versions included with sles11sp3.
System packages needed for the build were:
gcc-c++
make
readline-devel
libjpeg-devel
zlib-devel
patch
libopenssl-devel
libexpat-devel
man
All installed via zypper.
I'd advise not using sudo for the install. If you want to, you'll need to create the plone_daemon and plone_buildout users and the plone_group group in advance due to oddities in SUSE's adduser implementation.
For easy deployment, I'd like to ship an installation of Postgres as part of the application. Is it possible to include an already compiled and runnable version of Postgres that can be launched as process? I was able to do such thing with a Windows and MacOS version, but haven't found anything about Linux on that matter yet. Perhaps someone has tried this before and can share some insights...
You haven't stated what linux OS you're using.
Assuming it's a Redhat variant why not package your application as an RPM package? You could then declare a dependency on the standard Postgres package which would be automatically installed yum. Same principle applies if you're using Debian based systems, just a different packaging format.
From the user's perspective the OS's native packaging format is always the easiest way to install your application. Just requires effort to package it properly.
You can find cross-platform binaries from these pages on PostgreSQL official website:
For easy GUI .run installers, use links provided at http://www.enterprisedb.com/products-services-training/pgdownload.
If your target machine has no X installed on it, or you want to automate installation process with shell scripts, then you can download RPM or Deb packages from http://community.openscg.com/se/postgresql/packages.jsp
I found these links on http://www.postgresql.org/download/linux/ubuntu/, under "Cross distribution packages" and "Graphical installer".
I quote from those pages:
Note: The cross distribution packages do not fully integrate with the platform-specific packaging systems.
You must have root priviliges to install these packages, however, none of your systems library files will be altered. The supporting libraries that these binaries require are included locally as part of the install. This is the "special sauce" that allows identical binaries to run on different linux distro's.
So there is this particular jython project that needs a couple of dependencies, such as Jenkins, some kind of subversion, and this needs to be done on windows.
Would it be sane of me to consider using pip to help install all of these items, or should I look elsewhere, such as NSIS?
Update:
I really should've rephrase this - my fault for asking the question late at night.
There's an automated testing project that has the following dependencies:
Java JDK
Jython
Ant
Robot Framework
subversion
Jenkins
I personally prefer to run on Linux, but people that need to use this are typically Windows users. I'm confident enough to write a script to install all of this on Linux, but what I want is to have a script / installer that would install the relevent tools.
I would prefer to have a single script to do all of this - it's easy on Ubuntu with apt-get; but on windows, this quickly becomes non-trivial.
What is the best way to try and do this? Should I create separate installers for separate OS
pip is the acronym for pip install packages, python packages, and it only install Python packages.
Since Jenkins and Subversion are not Python packages, as far as I know, you can't install them, and it is not "sane".
Unfortunately there is no single established tool to install everything in every platform.
Use pip to install all your python packages, and prefer to use virtualenv to create isolated Python environments to manage your projects.
Since pip only installs python packages and Jenkins isn't a python package (it's written in Java), you cannot use it to install those packages.
You should totally take a look to virtualenv, but if you need to do a "double click" installer for your project in Windows i think that NSIS is the way to go.
I am successfully using install4j to create an executable installer for Windows, Linux and OSX. The application is Java and it bundles JRE. Install4j creates installer for each specified platform using respective JRE. So far it worked great on Windows and it somewhat works on Linux and OSX (e.g. in new version of install4j, JRE for Java 1.8 is not bundled properly for linu, so the JRE is preinstalled, but it could be automated). It also allows you to run non-interactive installer.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.