I'm a RHEL newbie. I'm used to a non-Linux Unix, which has a fundamentally different way of dealing with packages.
I want to install ipython for a user on a vanilla RHEL7 system with yum as the package manager.
"yum install python" was fairly straightforward, but given that I'm new to the OS and I don't completely understand what ipython is, I am stumped as to how to proceed.
"yum install ipython" obviously doesn't work and every possible solution seems to require the installation of something else that I don't know how to install in a reasonable manner.
I am trying to keep things as generic as possible so it will be obvious how to update/remove software in the future, so anything that can be done with yum, would be probably preferable.
Installation instructions refer to pip, which I don't have. I possibly need setuptools to run pip, but I can't figure out the appropriate way to get that either. Maybe I can get one or either by installation the EPEL bundle of packages, but I can't find those for RHEL7, at least not in a way that doesn't seem like a "download and install this random file, trust us" method, which seems irresponsible.
Another option is anaconda. Again, there doesn't seem to be a yum-related way to install this, and anaconda itself is only a means to an end to download ipython, so that'd be two levels of abstraction away from the goal.
Additionally, do I even want "ipython" these days, or do I want "jupyter"?
All I care about is that the user should be able to type in "ipython" at the prompt and get the thing he is expecting.
Also, the python installed by yum is 2.7.5-48.el7, which does not seem to be current. I don't care about using the current version unless that prevents me from successfully installing ipython in some other manner, but I thought it might be relevant.
Any suggestions for how to install this thing is the most easily maintainable way? Do I not want the yum version of python?
Thanks for your patience.
Install python-pip from EPEL repository first ( https://fedoraproject.org/wiki/EPEL - it's compatible with all Red Hat entrprise Linux distros - be it CentOS, RHEL, Oracl, ScientificLinux or whatever), (or if you don't trust EPEL repo providers you can use get-pip.py ( https://bootstrap.pypa.io/get-pip.py ) script, but then you have to trust its providers instead) then install via
pip install ipython
Related
Debian Jessie, as well as sid, have a mercurial-git package which contains the hg-git plugin. However, this package was (auto-)removed from Debian Stretch to to a release-critical bug.
But - I need it installed and running. Surely this should be possible, right?
Well, I followed the installation instructions on the plugin page:
I ran apt-get install python-setuptools python-setuptools-git python4-setuptools python3-setuptools-git
I ran easy_install hg-git and it seemed to work
But still, when I run various mercurial operations I get, as the first line, the error message:
*** failed to import extension hgext.git: No module named git
(regardless of whether I'm doing anything git-related or not.)
My questions:
Why is this happening?
What do I need to do in order to make the error message go away while having hggit working?
Now,
How do I correctly install dulwich to get hg-git working on Windows?
Apparently, that critical bug doesn't manifest always (and perhaps only under very specific circumstances), so you can try installing the Debian sid version of the mercurial-git package (that is, version 0.8.11-1 at the time of writing). There's a SuperUser question about how to do this:
https://linuxaria.com/howto/how-to-install-a-single-package-from-debian-sid-or-debian-testing
my personal opinion in this case is to simply install the .deb file, which you can get from here (it's not platform-specific; at the link you'll need to choose a mirror.) That makes the error message go away, at least assuming you have:
[extensions]
hgext.bookmarks =
hggit =
in your ~/.hgrc file.
I am trying to install Monitorix; but I can't seem to overcome certain issues with the required modules.
I have every prerequisite except for three of the perl modules (MIME-Lite, HTTP-Server-Simple, and Config-General). Even though I have installed them using CPAN, I can't seem to use rpm or yum to finish the installation process (I have the monitorix-3.9.0-1.noarch.rpm file downloaded).
Is there something I'm missing, or some way that is much easier to go about this? I started with a bare-bones Centos 7 system, in accordance to the nature of the course I have to do this for. Anything would be helpful, at this point.
Installing with CPAN is not the equivalent of installing them with yum; the installs are not in the RPM Database. Uninstall them and try again with yum, e.g. yum install perl-MIME-Lite.
While loading necessities into my crouton, apt-get recommended that I install libtemplate-perl. This seemed a jolly idea, and I obeyed.
Reading this answer, I see a fellow traveler install Plack and Starman via CPAN, but then use apt-get to install Dancer.
Minutes before reading said answer, I had installed Dancer via CPAN. And it had worked. It had worked real good!
What happens differently when I install a CPAN package via a non-CPAN package manager? Are there pitfalls I need to be wary of because my libtemplate-perl came from apt-get, or my Dancer came from CPAN?
On Debian or Debian based distros like Ubuntu, CPAN (/usr/bin/cpan utility) installs modules into /usr/local/lib/ by default. And Debian packages keep their files in /usr/share/perl5/ and /usr/lib/perl5/.
It's a better way to choose dh-make-perl tool to package any CPAN distribution not available in your apt repositories, to avoid making mess (serious risk of conflict between apt and CPAN):
dh-make-perl --build --cpan Some::Module
dpkg -i some-module*.deb
Also check out about local::lib and perlbrew.
A lot of tutorials, Stack Overflow answers, walk throughs, etc. will not want to assume that you know how to use /usr/bin/cpan and will instead suggest that you use your system's package manager, which you are more likely to be familiar with.
This is especially true if you are using a tool written in a particular language, but you don't know that language. For example many people wouldn't care whether crouton is written in Perl, Python or Lisp, they just want a tool they can use. Your average Debian or Ubuntu user is more likely to be familiar with apt-get than with cpan.
If you are looking to program in Perl I recommend installing things by cpan, using perlbrew and/or local::lib. If you are just looking to install a tool you can use, I would recommend using apt-get.
Additionally apt-get has the advantage that non-Perl dependencies will be installed automatically. For example the CPAN module XML::LibXML requires that the libxml2 headers are available on the system; the CPAN distribution has no way of stating that as a dependency, and will simply fail on install if it can find the headers to link against. The Debian package can actually specify that libxml2 is a dependency, and will install the dependency automatically for you.
Despite that if you are looking to use XML::LibXML as a Perl programmer, I would recommend installing it with cpan and installing the libxml2 package via apt-get. Having all your Perl modules installed in the same place - again, via perlbrew or local::lib - will help you keep your sanity in the future. CPAN is preferable to apt-get in this case because not all distributions have been packaged for Debian, and so you get a lot more options if you use CPAN directly.
In summary: TIMTOWTDI ;-)
Another difference to mention that I don't see in other answers, is that if you use CPAN to install a module then the module version you get will be set, until you decide to upgrade that module. Whereas, if you use apt and a later version appears in Debian at some point in the future, then apt-get upgrade will update it.
Maybe you want that, maybe you don't. It's neither necessarily an advantage, nor a disadvantage. Simply a difference to be noted.
The good things about apt-get are
that you can uninstall the packages afterwards should you need to
if you are maintaining any number of servers it is quicker to use apt-get as there is no building required
there are definite versions of packages which are tested for compatibility
The downsides are
not necessarily the latest version of packages
not all packages are available
apt-get installs are generally easier and better than cpan because of dependencies alone.
If you are so lucky as to need SOAP::Lite, for example, it is many dozens of dependencies, and a one-line "apt-get install libsoap-lite-perl".
It is sometimes not clear how Perl CPAN names map to their repository package names, but "apt-cache search " is your friend.
Another approach, that can be used for any distro in HOME install as simple user:
Pros
avoid conflicts
up to date version of perl and modules
when you reinstall, you keep your home/perl as-si
you can upgrade all installed modules with $ cpan -r
Cons
you need to upgrade Perl manually
How to
Edit ~/.bashrc or such, and add:
export PERL5LIB=~/localperl/lib/
export PATH=~/localperl/bin:$PATH
Then
source ~/.bashrc
Install latest Perl5 from sources: https://www.cpan.org/src/README.html
Now, you have an isolate Perl installation in your home.
Enjoy the power to install any libs via:
$ cpan -i Whatever::Module
I was using ubuntu 12.04 until 12.10 was released. I used ubuntu for software development and after installing 12.10, i noticed that the perl version (5.14) shipped with 12.10 does not include the Switch.pm module needed while building WebKiT-GTK.
Looking around on the internet i found few suggestions indicating that i should install something call p5-switch from something called ports. I have looked around and was not able to get this done. I am not a perl guy and have no idea where i can get this package.
Can someone please help me as to
1. Where to download the package for ubuntu 12.10
2. In case it is not a .deb, How do i install it.
OR
1. At least be able to downgrade the perl installation to something lower than 5.14
Thanks and Regards
~Sameer
sudo apt-get install libswitch-perl
will install it for you.
"ports" is a *BSD packaging system of sorts, not what you should be looking for.
You can find what package has a particular perl module by going to packages.ubuntu.com, entering Module/Name.pm (in this case, Switch.pm) in the "Search the contents of packages" form and checking "packages that contain files whose names end with the keyword" and selecting the desired distribution, then making sure you ignore false hits like CGI/Switch.pm in the results. Debian has the identical search for its packages at packages.debian.org.
(Note that Switch.pm has serious limitations, was never really intended to be used in production, and should certainly not be used in new code.)
Do make sure you've checked properly that there isn't the Switch module available via apt. If it is available, that's the one you want.
No, then you've two options the longer, correct way and a shorter way that's not quite as clean.
1. Longer
Install cpanm and perlbrew with apt. The perlbrew tool lets you install a complete version of Perl from scratch in a separate directory. Set up a user for your webkit building, run perlbrew as that user, install your perl. Then, use cpanm to install required modules and you are done. A bit of googling will get you step-by-step examples of how to use these tools. If anything goes badly wrong, you can just delete all the files in that user's home directory and start again - all you waste is a little time.
The reason experienced Perl people prefer this is that it keeps the perl you want for webkit-gtk separate from your system perl that ubuntu's packages will expect to be unchanged from the one they ship.
2. Shorter
Install cpanm with apt. As root, run "cpanm Switch" and it will install the Switch.pm package and any dependencies. It will also upgrade any already installed packages it thinks it needs to. This last step is why this option isn't ideal. In the (rare) case when the update isn't compatible with something else on your system uninstalling is fiddly.
I'm trying to setup a Perl development environment on my Mac laptop and have been having a really hard time getting it working. I thought I had everything configured correctly but when I try to run a sample script it is reporting errors with the DBI module and can't access the DB.
Here is what is reported in the Apache error logs:
[Fri Apr 30 23:11:33 2010] [error] [client 127.0.0.1] Can't locate DBI.pm in #INC (#INC contains: /Library/Perl/Updates/5.10.0/darwin-thread-multi-2level /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at main.pm line 5.
I downloaded and installed both modules manually to work with MAMP using the following commands as specified in this forum post:
For DBI
1. cd /Library/Perl/DBI-1.611
2. sudo Perl Makefile.PL
3. sudo make
4. sudo make install
For DBD
1. cd /Library/Perl/DBD-mysql-4.014
2. sudo Perl Makefile.PL --mysql_config=/Applications/MAMP/Library/bin/mysql_config
3. sudo make
4. sudo make install
What I noticed while running the above commands is that the files seems to be getting installed in the '/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/' directory which doesn't seem to be one of the search directories that Apache mentions in the error at the beginning of this post. Here is what I'm seeing during the install:
$ sudo make install
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBI.bundle
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbipport.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/DBIXS.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/dbixs_rev.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver.xst
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/Driver_xst.h
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/TASKS.pod
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/DBM.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/File.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBD/Gofer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Changes.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/DBD.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/Profile.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/ProxyServer.pm
Installing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/DBI/PurePerl.pm
Installing /opt/local/share/man/man3/DBD::DBM.3pm
Installing /opt/local/share/man/man3/DBD::File.3pm
Installing /opt/local/share/man/man3/DBD::Gofer.3pm
Installing /opt/local/share/man/man3/DBI.3pm
Installing /opt/local/share/man/man3/DBI::DBD.3pm
Installing /opt/local/share/man/man3/DBI::Profile.3pm
Installing /opt/local/share/man/man3/DBI::ProxyServer.3pm
Installing /opt/local/share/man/man3/DBI::PurePerl.3pm
Installing /opt/local/share/man/man3/TASKS.3pm
Installing /opt/local/bin/dbiprof
Installing /opt/local/bin/dbiproxy
Writing /opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI/.packlist
Appending installation info to /opt/local/lib/perl5/5.8.9/darwin-2level/perllocal.pod
My question is, what am I doing wrong and how can I either 1) Get Apache to look in the right directory where the DBD & DBI modules are installed or 2) Update the way I'm installing the module to install them into one of the search directories. I honestly don't know what option makes more sense and could use guidance on that as well.
As you can probably tell I'm pretty lost at the moment. Please help!!! Thanks in advance.
It looks like you've already installed another Perl via macports (/opt/local is where all macports installations go), and /opt/local/bin is earlier in your $PATH than the system Perl in /usr/bin. That's fine, if you are happy running Perl 5.8.9 rather than Perl 5.10.0 (hint: if you aren't sure of the differences, then the differences don't matter).
It's usually advised to not make extra installations to the system Perl. Apple may upgrade components through regular system updates, which could interfere with any modifications you have made, and if you make a mistake with an installation, it's difficult to remedy it without doing a full system reinstallation or having some serious understanding of the operating system guts. So, since you've already got another Perl installation ready, I would strongly encourage you to stick with that one.
However, you probably shouldn't be manually installing libraries if there is already a distribution available on macports. I used port search dbi and port search dbd to find them: the distributions are named p5-dbi and p5-dbd-mysql. You can install those like any other macports module: with sudo port install <distroname>. (You may need to install mod_perl itself, too.)
After that, you simply need to tell Apache/mod_perl to use that Perl installation rather than the system perl. I've never done that, so I can't advise on the best way to do it. However, quick searches on http://superuser.com suggest that the macports version of apache will run by default (via the same $PATH ordering), so I'd just Try It And See :).
Great answer, Ether. Having done this far too many times to count, I can give you a few pieces of advice:
Note: I am apparently limited to a single link in the post, so I had to remove all of my annotations. Thankfully, there is Delicious where I've stored them all with a stackoverflowmacports tag. Any place below where I removed a link to fit under Stack Overflow's ridiculous anti-spam measure, I've marked it with (*).
If having a reliably-working development environment at all times is important to you, rely on as LITTLE Mac OS X bundled software as possible. I love Apple but they have absolutely no qualms about breaking custom setups of their software as often as possible.
If #1 sounds like what you need to do, Macports is an EXCELLENT choice. I used to use Fink but they got left in the dust ages ago in terms of ease of use and spectrum of available software. The easiest route to installing macports is via the binary package install method (*)
As Ether mentions, when you have everything set up correctly, the Macports-provided MySQL, PHP and Apache all work together well without the system-installed analogs interfering. Most of that has to do with your PATH setting but all of those details are handled by the package installers post-flight script (*)
Once you're on the Macports train, it should become the very first place you look for any software. port search and port info are constant companions. They've got 6863 ports (*) currently which covers MOST of your bases.
When you do need to go outside of the Macports realm to find something, install it in /usr/local. That part of the file system hierarchy is yours to play with. Don't be lulled into a false sense of security and think that because Macports doesn't have what you're installing, it's okay to put it in /opt/local because invariably that software will install some dependency that will ALSO be a dependency for some piece of Macports software down the line and Macports will not allow a port to be installed if any one of its files would overwrite an existing file not managed by Macports (unless you force it which is always bad manners)
If you do any work with Perl and you use Macports' version, you will absolutely find yourself in a situation Macports doesn't have the one CPAN module you're looking for. (And, really, given that there are two and a half billion CPAN modules, who can blame them?). This will happen often enough that you will most likely tire of the manual installation method (*) (perl Makefile.PL; make; make test; sudo make install; cha; cha; cha) and long for the ease of use you've grown accustomed to with Macports.
If so, you can absolutely use the cpan (*) utility, CPANPLUS (*) or cpanminus (*) for all of your installing needs. Just make sure to make the necessary adjustments in the configuration of your tool of choice to instruct it to install your modules into /usr/local/lib/perl5, ignoring /opt/local/bin/perl's insistence that modules go into /opt/local/lib/perl5. You can set the PERL5LIB environment variable in your shell's init scripts to additionally look in /usr/local/lib/perl5 for modules. Just grab the #INC output from perl -V and tack it on the end...
And finally... Leveraging the system's daily init scripts or third-party software like Anacron (*) or MacPorts Notifier (*) (both available through MacPorts), make sure to update your software frequently. You don't have Mother Apple protecting you with Software Updates for the Macports installed software which have just as many bugs and security exploits as the very same software Apple bundles.
By updating frequently, you'll stay ahead of the baddies and by automating it, the upgrades will actually happen and you won't end up as I have in the past with a full weekend blown because you had a mountain of outdated ports to upgrade. Note: Macports stages its updates and if it fails at any point, your current version continues to work. Apple could learn a thing or two from them, I tell ya...
So, that's all I can think of a the moment. Hopefully the lessons above will get you going quickly and save all of the time, effort and stress I've experienced in past years in learning it. I would argue it's still far better than the alternative: Hating Apple because they break all of your nice things... :-)
I had a similar problem with Apache using the wrong Perl. I fixed it by appending the following lines to my httpd.conf file:
SetEnv PATH [colon-separated list of directories]
SetEnv PERL5LIB [colon-sep'd list of directories]
In my case, it looked like this:
SetEnv PATH /opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/mysql/bin:$PATH
SetEnv PERL5LIB /opt/local/lib:/usr/local/lib