I have node v15.10.0 installed. I dont know how it was installed.
I found this article on how to update node. For mac it recommends using the official binary installer, which I did. It says the new version should overwrite the old version.
After installation, if I open a new terminal and do node --version, it stills says 15.10.0
The question is, how do I fully delete the old version, and install the new?
My path looks like this:
/Users/xx/.nvm/versions/node/v15.10.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/opt/apache-maven/bin
I presume I could hack the path using a shell script, but is there a better way? Why did the installer not do this for me?
If we have to hack the path (for each user), which is the correct file? I see there is a .bashrc and a .zprofile in my home dir. They are not linked, but they have identical content, which is bazare, and they do not contain code to add /Users/xx/.nvm/versions/node/v15.10.0/bin to the path, so this must be set outside of either file?
I cant see 15 path in /etc/paths either.
I have no idea what shell you get in Mac now a days, but if I do ps -ef I see it mentions both bash and zsh.
Presumably I need to change the path on both ?
if you have nvm installed, the best way is :
nvm install 16
To switch between installed node version:
nvm use 16
To set default node version:
nvm alias default 16
Thanks to #AKX this was the solution:
nvm uninstall 15.10.0
Now I see v16.
On my Mac terminal i've installed python3 (3.7.6) using homebrew - e.g. if I issue command to upgrade via homebrew, it returns the up to date version:
$brew upgrade python3
Warning: python3 3.7.6_1 already installed
However when I ask for the version it tells me an older version (3.4.0) is installed:
$python3 --version
Python 3.4.0
So it's installed but not updated. I'd quite like 3.6 or later on my mac. I've tried uninstalling and reinstalling using homebrew, and had no luck. Wondering if anyone has any ideas?
//
Sidenote (1) - i'm relatively new to homebrew... $ brew doctor returns config scripts "outside your system or Homebrew directories" - not sure if this helps, and if this is the issue where to move them to.
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4m-config
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3-config
/Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4-config
Sidenote (2) - 3.7.6 isn't the newest version out, but this is the latest version that homebrew will install. Is there any way to get an even newer version?
By chance i've come across the/a answer. I was editing .bash_profile and saw the very top says:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
So I moved to this directory .../Versions/, found it had three subdirectories 3.3, 3.4, and 3.8, and updated to use:
PATH="/Library/Frameworks/Python.framework/Versions/3.8/bin:${PATH}"
And this seems to do the trick (to use the most recent). Although interestingly i've not came across 3.7.6... but is a bit redundant in my case since I can use the newer 3.8 version.
Quick fix:
You should be able to run the required version by running python3.7 instead of python3. You can set up an alias if you like with
"alias python=/usr/local/bin/python3.7"
where you put the desired binary on the RHS. This will create an alias for your current session. To always evoke this functionality, you can add this line to your bashrc file so this alias will work every time you log in to a new session
echo "alias python=/usr/local/bin/python3.7" >> ~/.bashrc
These commands were lifted from
https://opensource.com/article/19/5/python-3-default-mac
which explains some do and do-nots.
Alternative:
Also check out Python virtual environments, particularly virtualenv and virtualenvwrapper, which are great tools for separating out your Python working environments and allow you to set default Python version for each project separately, as well as managing any modules you pip install separately for each project. This is much cleaner in my opinion.
https://www.bogotobogo.com/python/python_virtualenv_virtualenvwrapper.php
I am working on some projects using Julia v0.3. However, I'd like to test my code in both v0.3 and v0.4 (since some of the people that are going to be using it are already using v0.4). I'm running Ubuntu 14.04 and have installed Julia using apt-get. I know v0.4 is available through the PPA julianightlies, but if I add this, v0.3 is replaced. Is there a way I can install and quickly switch between both versions for testing purposes?
You can install different versions of Julia in different locations and set separate symlinks.
For example, you could download the v0.3 Linux binaries and install them to one location, then clone the GitHub source for v0.4 and install that in another location. Then set symlinks such as julia3 for v0.3 and julia4 for v0.4.
Run your code like:
$ julia3 somefile.jl
$ julia4 somefile.jl
Install by compiling and then change your she-bang in the start of the file as
#!/path_to/julia3
or
#!/path_to/julia4
That will do the trick
I upgrade perl from perl58 to perl588 on Suse Linux.It looks that even though the Config.pm exists for the older version the newer version installation breaks the older version.While the upgrade of Perl on other OSes like HP and AIX does not disturb the older version.
For eg: The perl58 and perl588 versions are present in folder say "/usr/standard_perl" as follows:
/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)
and have symbolic links pointing to it.
Before and after upgrade the links are as follows:
Before:
perl58_link -> /usr/standard_perl/perl58
After:
perl5_link -> /usr/standard_perl/perl588
perl58_link -> /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588
Now when i try to run simple "./perl -V" command from /usr/standard_perl/perl58/bin the older version complains of Config.pm not found even though its very well present in its own tree structure.
Is it that in Linux, perl is following a hard coded path for #INC.This kind of behaviour is observed only on Linux.
I am worried for I cannot roll to production for there are scripts that have been running for older version and if this kind of behaviour exists I would need to know if its possible to fix or this is a known behaviour of Linux.
I am not sure could this be because now the older links after upgrade is been pointed to newer version and just linking is not sufficient and need to modify something more on LINUX?
Note:
1.The perl modules are seperately maintained for each version
2.I am not mixing any of the files with previous version.
3. We want all of the old perl scripts running in production servers not to break and use latest version instead for the mainatainence of Perl versions.
3a.Hence a need to tweak the links pointing to latest version instead of their own versions.
Observation:
Only on Linux seeing this behaviour.
One point worth noting is when i twek links of older version to latest version. the #INC automatically is updated for latest version INC and not in LINUX.
Am i missing something here?
I've never seen this problem on Linux. I leave the original perl in its location (/usr/bin/perl), and simply compile my own perl to install to /usr/local/bin (or whatever), and have never seen any breakage of the old version.
You don't say
how you came to have a /usr/standard_perl/perl588 (compiled, given in rpm format or something, pre-compiled tarball, ...)
what options you used when configuring the compilation
You're also very vague with your details - perl58_link, standard_perl, etc. - where is this really? Most of the time it doesn't matter, but sometimes it does.
If you move the link back, do things start to work? If you move the entire 5.8.8 tree somewhere else, do things start to work? Can you recover your base perl from RPM or whatever to try to make it work? IMO, the base perl working is paramount, a secondary perl is always bonus. (I'd take the same opinion of other core unix tools, like shells, awk, sed, or even python or whatever your distro uses for package management. Less so for non-core tools like Java, but if I were running Java apps in production then I'd say the same here, too.)
Leave the system perl executable alone, compile your own, and have your Perl programs run using the one you compiled
All system programs written in Perl should start with:
#! /usr/bin/perl
All non-system Perl programs, user written programs:
This one will use which ever perl executable is found first on $PATH. (same as 'which perl')
#! /usr/bin/env perl
Another option is to specify exactly where the executable you want to use is:
#! /opt/bin/perl
#! /opt/perl/bin/perl
#! /opt/perl/5.10.0/bin/perl
#! /opt/perl-5.10.0/bin/perl
#! /home/$user/perl/bin/perl
#! ~/bin/perl
Or what ever the path to the perl executable is.
Never replace /usr/bin/perl with one you compiled yourself!
I did this once on Ubuntu 7.10, and it broke my system. I could login, and do most everything, but I couldn't change the appearance, for example. I ended up running 'sudo nano $filename' on every Perl program on my computer, and change them so they would run under Perl 5.10, instead of Perl 5.8.
After which I had to install Ubuntu 8.10 from scratch, when it finally came out.
You could also experience incompatibilities if you use cpan or cpanp to install modules, because they could have an incompatible feature change. And for a non-binary compatible perl executable, you have to reinstall all modules that require XSubs.
Thats why all Perl programs that I write I add the header '#!/usr/bin/env perl', and add the path to the Perl executable, to the beginning of the $PATH variable.
A recent question here on SO got me thinking.
On most Linux distributions that I tried, some Perl modules would be available through the package manager. Others, of course, not. For quite a while I would use my package manager whenever I needed to install some CPAN module to find out whether a package was available or not and to install it when it was.
The obvious advantage is that you get your modules updated whenever a new version of the package becomes available.
However, you get in trouble when the module is not available in pre-packaged form and there are dependencies for that module that are. Firing up your package manager every time the cpan shell asks whether it should follow a dependency can be quite tiring.
Often, another drawback is the version of the pre-packaged module. If you are running Debian or Ubuntu you will soon find out that you will not be able to live on the bleeding edge, like many CPAN module authors seem to do.
How do other Perl people on Linux handle that problem? Do you just ignore what your package managers have to offer? Are there any tools that make apt (for example) and cpan better team mates? Or do you simply not install anything via the cpan shell?
For development, I install my own Perl and leave the system Perl alone. If I want to upgrade the system Perl, I use the system package manager. For my development Perl, I use the cpan tool.
Since I keep those separate, I should never mess up the Perl that the system needs for its maintenance tasks and so on, but I don't have to rely on the system's decisions for development.
It's very easy to install separate Perls. When you run Configure from the source distribution, it will ask you where you want to install everything. Give it any path that you like. I have many Perls installed in /usr/local/perls, for instance, and everything for each installation lives separately. I then make symlinks in /usr/local/bin for them (e.g. perl5.8.9, perl.5.10.0, perl5.10.0-threaded). When I want a particular version, I just use the one I want:
$ perl5.10.0 program.pl
The particular binary ensures that the program picks up the right module search path and so on (it's the same stuff in the Config.pm module for that binary).
Here's a script I use to create the symlinks. It looks in the bin directory, figures out the Perl version, and makes links like cpan5.10.1 and so on. Each program already knows the right perl to call:
#!perl
use 5.010;
use strict;
use warnings;
use File::Basename;
use File::Spec::Functions;
my $perls_directory = catfile(
$ARGV[0] // '/usr/local/perls',
'perl*'
);
die "$perls_directory does not exist!\n"
unless -d dirname $perls_directory;
my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;
foreach my $directory ( glob( $perls_directory ) )
{
say "Processing $directory...";
unless( -e catfile( $directory, 'bin' ) )
{
say "\tNo bin/ directory. Skipping!";
next;
}
my #perls = glob( catfile( $directory, qw( bin perl5* ) ) );
my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
say "\tperl version is $perl_version";
foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
{
say "\tFound $bin";
my $basename = basename( $bin );
my $link_basename = do {
if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
else { "$basename$perl_version" }
};
my $link = catfile( $links_directory, $link_basename );
next if -e $link;
say "\t\tlinking $bin => $link";
symlink $bin => $link or
warn "\t\tCould not create symlink [$!]: $bin => $link!";
}
}
Everything gets install in the right place for that particular Perl.
I've also been thinking that I should put those Perl directories under some sort of source control. If I add a module I don't like, I just back out to an earlier revision. I'm only starting to do that though and haven't played with it much.
I've written more about this sort of thing in the Effective Perler blog:
Make links to per-version tools.
Manage your Perl modules with Git.
We install everything via the CPAN shell. This does ignore what package managers have to offer, but it avoids the headaches you mention when trying to work with them (firing for dependencies, using correct versions).
In addition, it means that our packages can be built programatically (or manually via the shell) on any platform where CPAN runs. Having a dependency on a package manager would affect your ability to distribute your software to platforms that don't use/support that package manager.
Since this question was originally asked, perlbrew has been released. It makes installing custom, self-contained perl installs trivial. And switching between those versions is just as easy:
perlbrew switch $version
I am using Debian for development, and production, and rely on debian Perl packages that are provided with the distro.
For cases where I need a Perl module that is not available in debian, I usually create my own debian package of it and install it.
Ofcourse, this method is not without faults, as a a lot of debian perl modules are outdated (at least in the current debian stable version - etch), and backporting something like Catalyst which has lots of dependencies is not practical.
However, by relying on the OS package manager, I retain all the great features of it, which bring easy maintenance, especially for deployed servers, as you know exactly what packages are installed, and a simple apt-get update;apt-get upgrade (from debian, or from a local repository) upgrades all servers to the same state, including the Perl modules.
I do the following on all my boxes:
I compile my own perl: I still use 5.8.[89] mostly, the stock 5.10.0 has a performance regression that hits me a lot, waiting for 5.10.1 to try again;
I use (and strongly recommend) the local::lib module to keep a module directory per project. Right now, that directory is rsync'ed to all the servers where the project is installed, but I'm testing using git instead;
I create a Task:: module for each project, so that I can install all dependencies with a single command.
I also use the cpan shell and local::lib.
You shouldn't need a Task:: for each project. Just use Module::Install (I like to use Module::Starter like this:
$ module-starter --mi --module=Module::Name --author="Me" --email=me#cpan.org
and then just pop your dependencies in requires 'module::dependency'; in the Makefile.PL. Finally when it's install time, you just perl Makefile.PL (answer yes) then make installdeps
[edit 5 years on from when I gave this answer originally]
These days perlbrew and cpanm are the things to use. local::lib still has a use-case, but the combination of perlbrew and cpanm solve a superset of those cases. Use local::lib when you're not prepared to compile your own perl.
I recommend use only cpan. The modules includes in Linux distro is only to cover package dependency. When you are installing linux without internet access with only CDs, it can't use cpan, so some modules are included as packages, but to a Perl developer this is bad.
Also I used to have a cpan configured to install modules in my home, (.perl) without root login needed.
For production:
In development, choose a version of the perl module which seems right for the requirements; if possible choose the target OS's shipped version (this makes most of the following superfluous), otherwise, pick another one. Create a RPM spec file for it. Use the clean build VM to build the RPM in a reproducable way (from a specfile / source checked in on the appropriate branch).
When the final build can be built (after merge), do the same build from the release branch, commit generated RPMs into deployment repository. This will be used in final validation and then released to production by being copied to the production repository.
All servers in production use the exact same binary that has been fully tested; they use the same spec file and source as the developer intended.
Perl modules are NOT upgraded by any process which does not follow this model. Nor is any other production software.
I use FreeBSD ports and wrap up all the CPAN dependencies in a "meta port" as a sort of a local port. FreeBSD has quite a large number of CPAN modules and their build system is approachable enough that you can easily write your own port if it doesn't exist--just dont forget to submit said port so it gets included in the ports tree. If the port doesn't have the current version in stock, you can always edit the Makefile for the port so it uses the new version, again don't forget to submit the change :-).
Lastly, I use Tinderbox to build the whole mess as binary packages that I then install on the all the production and development machines.
Bottom line--Once you get over your phobia of editing Makefiles, FreeBSD's ports are a great way to maintain your perl application and its dependencies.
I have started using Gentoo recently and Gentoo has a few very important advantages in this area. The first is that g-cpan is capable usually of installing many (though not all) modules from CPAN as Gentoo packages natively, though updating becomes a bit of a problem.
Usually on Gentoo, my approach is to use g-cpan to create an ebuild file, then install from that, tweaking if necessary. The advantage is that upgrading becomes really easy. I then move the file from g-cpan/perl to dev-perl and put it in an overlay for others to use. This allows me to quickly handle the cases g-cpan does not and gentoo packaging is a breeze anyway/