I tried doing the following. First, I install a relocatable perl, e.g.:
% perlbrew -Duserelocatableinc -j4 -n --as perl-5.28.1-fresh_src 5.28.1
Then, whenever I need a new throw-away fresh installation of perl to test things out, I do:
% cp -la ~/perl5/perlbrew/perls/perl-5.28.1-fresh{_src,1}
% perlbrew switch 5.28.1-fresh1
(then would later create fresh2, fresh3 and so on as needed; and when I want to throw these away I just rm -rf ~/perl5/perlbrew/perls/*fresh1 and so on.)
However, something (cpanm? EUMM?) is still confused. Scripts installed from CPAN still has the original perl path (in this case, /home/USER/perl5/perlbrew/perls/perl-5.28.1-fresh_src/bin) in their shebang line.
Any hint to the problem above, or an alternative way to quickly create a fresh throw-away perl installation is appreciated. Also, would the -l (--link) option of cp in the above command cause issue (other than perllocal.pod being appended and will contain installation records of perl installations, which is fine for me)?
It's not quite the same, but I find docker works if I'm needing a clean install for certain testing scenarios - build up a base image and a clean perl install, fire up the container and run 'whatever'.
You'll need root access and be able to install packages (e.g. docker) so it's not going to be suitable for every use case.
https://buildlogs.centos.org/centos/7/docker/ has a base image you can use to build a 'clean' CentOS (or use whatever OS you prefer frankly - most have container versions)
FROM scratch
ADD CentOS-7-20140625-x86_64-docker_01.img.tar.xz
LABEL name="CentOS Base Image"
CMD ["/bin/bash"]
In the working directory:
docker build -t mycentos .
This will give you a very basic image:
Then your perl dockerfile:
FROM mycentos
COPY local.repo /etc/yum.repos.d/local.repo
RUN yum clean all
RUN yum install --nogpgcheck -y make gcc tar
ADD perl-5.28.1.tar.gz /build/
RUN cd /build/perl-5.28.1 && ./Configure -de
RUN cd /build/perl-5.28.1 && make && make test && make install
COPY MyConfig.pm /root/.cpan/CPAN/MyConfig.pm
RUN cpan install Bundle::CPAN
CMD ["/bin/bash"]
You'll be able to spin this up, with e.g. docker run and invoke a script using /usr/local/bin/perl.
It's not quite what you asked for, but your base image can be started and discarded as you wish - you can maintain image for a few different OS and perl combinations too.
Related
While attempting to compile darknet in the build command of a docker container I constantly run into the exception include/darknet.h:11:30: fatal error: cuda_runtime.h: No such file or directory.
I am building the container from the instructions here: https://github.com/NVIDIA/nvidia-docker/wiki/Deploy-on-Amazon-EC2. I have a simple Dockerfile I am testing with - the relevant parts:
FROM nvidia/cuda:9.2-runtime-ubuntu16.04
...
WORKDIR /
RUN apt-get install -y git
RUN git clone https://github.com/pjreddie/darknet.git
WORKDIR /darknet
# Set OpenCV makefile flag
RUN sed -i '/OPENCV=0/c\OPENCV=1' Makefile
RUN sed -i '/GPU=0/c\GPU=1' Makefile
#RUN ln -s /usr/local/cuda-9.2 /usr/local/cuda
# HERE I have been playing with commands to show me the state of the docker image to try to troubleshoot the problem
RUN find / -name "cuda_runtime.h"
RUN ls /usr/local/cuda/lib64/
RUN less /usr/local/cuda/README
RUN make
Most of the documentation I see references using the nvidia libraries when running a container, but the darknet compiles differently when built with gpu support so I need cuda_runtime.h available at build time.
Perhaps I misunderstand what nvidia-docker is doing - I'm assuming that nvidia-docker exists because the Nvidia code must be installed on the actual host machine and not inside the container & they use some mechanism to share the "native" code with the containers so the GPU can be managed - is that correct?
Should I even be trying to build darknet when building my container or should I be installing it on the host machine, then making it available somehow to the container? This seems to go against the portability of the containers but I can live with some constraints to get access to the GPU.
FROM nvidia/cuda:9.2-runtime-ubuntu16.04
Your image only has bits and pieces of CUDA-9.2 needed to run a CUDA app, but does not have the bits needed to build one.
You need to use -devel variant.
I am trying to build an application release by using Snapcraft.io, and I have almost all working.Snapcraft already compiles the source code, generates the .snap file, includes all the dependencies, and so on.However, I am stuck at how I can initialize some configuration files in the SNAP_USER_DATA folder after the first app install.I do not want to place the files in the default read-only path SNAP, as the default parameters should be modified by the user, also I need to generate some additional files, like server certificates.So I need to copy some files, and also run a script after the first install. Is this possible?
Thanks.
Because snaps are installed as root, it's impossible to do exactly as you ask at install time, as $SNAP_USER_DATA is user-specific, so it'll always be root's. However, you can do this at install-time using a system-wide directory, such as $SNAP_DATA, using the install hook:
$ snapcraft init
Created snap/snapcraft.yaml.
Edit the file to your liking or run `snapcraft` to get started
Create the hook. In our case we'll just create a new file in $SNAP_DATA, but you could do whatever you wanted.
$ mkdir -p snap/hooks
$ echo "touch \$SNAP_DATA/foo" >> snap/hooks/install
$ chmod a+x snap/hooks/install
Build the snap.
$ snapcraft
Preparing to pull my-part
Pulling my-part
Preparing to build my-part
Building my-part
Staging my-part
Priming my-part
Snapping 'my-snap-name' |
Snapped my-snap-name_0.1_amd64.snap
Install the snap. This will run the install hook.
$ sudo snap install my-snap-name_0.1_amd64.snap --devmode --dangerous
my-snap-name 0.1 installed
Notice a file was created in $SNAP_DATA.
$ ls /var/snap/my-snap-name/current
foo
The only way to get similar functionality for $SNAP_USER_DATA would be to wrap your real command in a script that creates the config. This command is then run by the user, which means you get the $SNAP_USER_DATA you intend. Of course, this isn't at install-time.
I have a relatively big project that has many dependencies, and I would like to distribute this project around, but installing these dependencies where a bit of a pain, and takes a very long time (pip install takes quite some time). So I was wondering if it was possible to migrate a whole virtualenv to another machine and have it running.
I tried copying the whole virtualenv, but whenever I try running something, this virtualenv still uses the path of my old machine. For instance when I run
source activate
pserve development.ini
I get
bash: ../bin/pserve: /home/sshum/backend/bin/python: bad interpreter: No such file or directory
This is my old directory. So is there a way to have virtualenv reconfigure this path with a new path?
I tried sed -i 's/sshum/dev1/g' * in the bin directory and it solved that issue. However, I'm getting a different issue now, my guess is that this sed changed something.
I've confirmed that I have libssl-dev installed but when I run python I get:
E: Unable to locate package libssl.so.1.0.0
E: Couldn't find any package by regex 'libssl.so.1.0.0'
But when I run aptitude search libssl and I see:
i A libssl-dev - SSL development libraries, header files and documentation
I also tried virtualenv --relocatable backend but no go.
Export virtualenvironment
from within the virtual environment:
pip freeze > requirements.txt
as example, here is for myproject virtual environment:
once in the new machine & environment, copy the requirements.txt into the new project folder in the new machine and run the terminal command:
sudo pip install -r requirements.txt
then you should have all the packages previously available in the old virtual environment.
When you create a new virtualenv it is configured for the computer it is running on. I even think that it is configured for that specific directory it is created in. So I think you should always create a fresh virtualenv when you move you code. What might work is copying the lib/Pythonx.x/site-packages in your virtualenv directory, but I don't think that is a particularly good solution.
What may be a better solution is using the pip download cache. This will at least speed up the download part of pip install. Have a look at this thread: How do I install from a local cache with pip?
The clean way seems to be with virtualenv --relocatable.
Alternatively, you can do it manually by editing the VIRTUAL_ENV path in bin/activate to reflect the changes. If you choose to do so, you must also edit the first line (#) of bin/pserve which indicates the interpreter path.
Is there a tool in the Cygwin package similar to apt-get on Debian or yum on redhat that allows me to install components from the command line?
Cygwin's setup accepts command-line arguments to install packages from the command-line.
e.g. setup-x86.exe -q -P packagename1,packagename2 to install packages without any GUI interaction ('unattended setup mode').
(Note that you need to use setup-x86.exe or setup-x86_64.exe as appropriate.)
See https://cygwin.com/packages/ for the package list.
For a more convenient installer, you may want to use
apt-cyg as your package manager. Its syntax similar to
apt-get, which is a plus. For this, follow the above
steps and then use Cygwin Bash for the following steps
wget https://raw.githubusercontent.com/transcode-open/apt-cyg/master/apt-cyg
chmod +x apt-cyg
mv apt-cyg /usr/local/bin
Now that apt-cyg is installed. Here are few examples of
installing some packages
apt-cyg install nano
apt-cyg install git
apt-cyg install ca-certificates
There is no tool specifically in the 'setup.exe' installer that offers the
functionality of apt-get. There is, however, a command-line package installer
for Cygwin that can be downloaded separately, but it is not entirely stable and
relies on workarounds.
apt-cyg: http://github.com/transcode-open/apt-cyg
Check out the issues tab for the project to see the known problems.
There exist some scripts, which can be used as simple package managers for Cygwin. But it’s important to know, that they always will be quite limited, because of...ehm...Windows.
Installing or removing packages is fine, each package manager for Cygwin can do that. But updating is a pain since Windows doesn’t allow you to overwrite an executable, which is currently running. So you can’t update e.g. Cygwin DLL or any package which contains the currently running executable from the Cygwin itself. There is also this note on the Cygwin Installation page:
"The basic reason for not having a more full-featured package manager is that
such a program would need full access to all of Cygwin’s POSIX functionality.
That is, however, difficult to provide in a Cygwin-free environment, such as
exists on first installation. Additionally, Windows does not easily allow
overwriting of in-use executables so installing a new version of the Cygwin
DLL while a package manager is using the DLL is problematic."
Cygwin’s setup uses Windows registry to overwrite executables which are in use
and this method requires a reboot of Windows. Therefore, it’s better to close
all Cygwin processes before updating packages, so you don’t have to reboot
your computer to actually apply the changes. Installation of a new package
should be completely without any hassles. I don’t think any of package managers
except of Cygwin’s setup.exe implements any method to overwrite files in use,
so it would simply fail if it cannot overwrite them.
Some package managers for Cygwin:
apt-cyg
Update: the repository was disabled recently due to copyright issues (DMCA takedown). It looks like the owner of the repository issued the DMCA takedown on his own repository and created a new project called Sage (see bellow).
The best one for me. Simply because it’s one of the most recent. It doesn’t use Cygwin’s setup.exe, it rather re-implements, what setup.exe does. It works correctly for both platforms - x86 as well as x86_64. There are a lot of forks with more or less additional features. For example, the kou1okada fork is one of the improved versions, which is really great.
apt-cyg is just a shell script, there is no installation. Just download it (or clone the repository), make it executable and copy it somewhere to the PATH:
chmod +x apt-cyg # set executable bit
mv apt-cyg /usr/local/bin # move somewhere to PATH
# ...and use it:
apt-cyg install vim
There is also bunch of forks with different features.
sage
Another package manager implemented as a shell script. I didn't try it but it actually looks good.
It can search for packages in a repository, list packages in a category, check dependencies, list package files, and more. It has features which other package managers don't have.
cyg-apt
Fork of abandoned original cyg-apt with improvements and bugfixes. It has quite a lot of features and it's implemented in Python. Installation is made using make.
Chocolatey’s cyg-get
If you used Chocolatey to install Cygwin, you can install the package cyg-get, which is actually a simple wrapper around Cygwin’s setup.exe written in PowerShell.
Cygwin’s setup.exe
It also has a command line mode. Moreover, it allows you to upgrade all installed packages at once (as apt-get upgrade does on Debian based Linux).
Example use:
setup-x86_64.exe -q --packages=bash,vim
You can create an alias for easier use, for example:
alias cyg-get="/cygdrive/d/path/to/cygwin/setup-x86_64.exe -q -P"
Then you can, for example, install Vim package with:
cyg-get vim
First, download installer at: https://cygwin.com/setup-x86_64.exe (Windows 64bit), then:
# move installer to cygwin folder
mv C:/Users/<you>/Downloads/setup-x86_64.exe C:/cygwin64/
# add alias to bash_aliases
echo "alias cygwin='C:/cygwin64/setup-x86_64.exe -q -P'" >> ~/.bash_aliases
source ~/.bash_aliases
# add bash_aliases to bashrc if missing
echo "source ~/.bash_aliases" >> ~/.profile
e.g.
# install vim
cygwin vim
# see other options
cygwin --help
I wanted a solution for this similar to apt-get --print-uris, but unfortunately apt-cyg doesn't do this. The following is a solution that allowed me to download only the packages I needed, with their dependencies, and copy them to the target for installation. Here is a bash script that parses the output of apt-cyg into a list of URIs:
#!/usr/bin/bash
package=$1
depends=$( \
apt-cyg depends $package \
| perl -ne 'while ($x = /> ([^>\s]+)/g) { print "$1\n"; }' \
| sort \
| uniq)
depends=$(echo -e "$depends\n$package")
for curpkg in $depends; do
if ! grep -q "^$curpkg " /etc/setup/installed.db; then
apt-cyg show $curpkg \
| perl -ne '
if ($x = /install: ([^\s]+)/) {
print "$1\n";
}
if (/\[prev\]/) {
exit;
}'
fi
done
The above will print out the paths of the packages that need downloading, relative to the cygwin mirror root, omitting any packages that are already installed. To download them, I wrote the output to a file cygwin-packages-list and then used wget:
mirror=http://cygwin.mirror.constant.com/
uris=$(for line in $(cat cygwin-packages-list); do echo "$mirror$line"; done)
wget -x $uris
The installer can then be used to install from a local cache directory. Note that for this to work I needed to copy setup.ini from a previous cygwin package cache to the directory with the downloaded files (otherwise the installer doesn't know what's what).
Old question, but still relevant. Here is what worked for me today (6/26/16).
From the bash shell:
lynx -source rawgit.com/transcode-open/apt-cyg/master/apt-cyg > apt-cyg
install apt-cyg /bin
Dawid Ferenczy's answer is pretty complete but after I tried almost all of his options I've found that the Chocolatey’s cyg-get was the best (at least the only one that I could get to work).
I was wanting to install wget, the steps was this:
choco install cyg-get
Then:
cyg-get wget
Usually before installing a package one has to know its exact name:
# define a string to search
export to_srch=perl
# get html output of search and pick only the cygwin package names
wget -qO- "https://cygwin.com/cgi-bin2/package-grep.cgi?grep=$to_srch&arch=x86_64" | \
perl -l -ne 'm!(.*?)<\/a>\s+\-(.*?)\:(.*?)<\/li>!;print $2'
# and install
# install multiple packages at once, note the
setup-x86_64.exe -q -s http://cygwin.mirror.constant.com -P "<<chosen_package_name>>"
Is it possible?
If you download the source code, and read the README file. This will probably tell you you should do
perl Makefile.PL
make
make test
make install
or
perl Build.PL
./Build
./Build test
./Build install
If you download the source code, it will generally have a Makefile.PL. You run "perl Makefile.PL; make; make test; make install" and it will build and install for you.
Obviously if you're not using CPAN.pm, you're going to have to deal with dependencies yourself.
Also, if the reason you can't use CPAN.pm is that you don't have permission to install into /usr/lib/perl, you can force CPAN.pm to install locally, but I forget how.
If you are on a Linux box, a very large portion of the packages can usually be obtained using the built in package manager. For instance, on an Ubuntu system, if you want to install the PostgreSQL Perl module you'd simple do:
sudo apt-get install libpg-perl
You can see a list of the modules for Ubuntu here: http://packages.ubuntu.com/hardy/perl/
I find I can often guess at the names myself. Not sure if this helps at all, but for myself I often find this easier to use than CPAN as it does a lot better at resolving dependencies.
See here: How to install perl modules using CPAN without root
I have just set this up on a server without root access and CPAN does everything automatically.
But if you really wanna install a module without CPAN and you don't have root (assuming this since you don't wanna use CPAN), you can do it as follows
perl Makefile.PL PREFIX=$HOME
make
make install
You're gonna have to hunt down dependencies yourself so it's better to use CPAN.
If the problem is no root access, I would recommend looking at local::lib and also this webpage for CPAN.pm and non-root installation.
But to answer the question as asked, CPAN or CPANPLUS are helpful, but they aren't required. You can always do it the old-fashioned way as Leon says - though usually, it's easier not to.
If you are using Red Hat (Fedora, CentOS), you should use RPM for Perl dependencies wherever possible. Perl packages are almost always named perl-Module-Name, e.g. perl-DBI, perl-Spreadsheet-WriteExcel, etc.
On Ubuntu the naming scheme is libmodule-name-perl.
If the .pm file is pure Perl and doesn't need to be compiled you can just put it in your application's lib folder and use it as normal.
We can install all perl modules both from and even with your terminal in ubuntu. If you are using a ubuntu server then execute the following command ,
'sudo apt-get install "perl_module"'
The modules which you want just give the name in "perl_module" means If you want to install Apache2::Cookie it will be in "libapreq2" so you have to give like,
"sudo apt-get install libapreq2"
I, as others have would highly suggest using CPAN.pm. It is a breeze to use and can resolve any dependencies associated with the module you need automatically.
On the other hand, I would suggest that you read the perlmodinstall document over at perldoc as it gives details on other os' as well.
Regards,
Jeff
If you're asking this because you're having problems with CPAN... you're probably running out of RAM that's why you can't use CPAN.
Maybe you don't have a swap file. Try this:
$ sudo su
# dd if=/dev/zero of=/swap bs=1M count=1k # create a 1GB file
# mkswap /swap
# swapon /swap
Otherwise... stop some services.
$ sudo service mysql stop
$ sudo service nginx stop
...And try again
$ cpan install CPAN
$ cpan install MIME::Lite::TT::HTML