Julia adding package from github - julia

I want to install the following package from github. I tried using the following command in my environment to install
(nlpEnvJl) pkg> add "https://github.com/yeesian/LeafletJS.jl/tree/master/src"
But I get the following error,
ERROR: could not find project file in package at https://github.com/yeesian/LeafletJS.jl maybe subdir needs to be specified
Any ideas on how I can get installed? Do I have to clone it first to my local repo? If so how do I install from local path?
Cheers
Thanks in advance

You do not need to install locally, but you have to put the URL official to clone it.
add https://github.com/yeesian/LeafletJS.jl.git
Sometimes, if the package is already registered and you only want the master version in github you can directly do
add PackageName#master

You have to clone it locally and then use Pkg.generate in order to import it as a package. It needs a Project.toml file to be added.
Thus, you have to:
$ git clone git#github.com:yeesian/LeafletJS.jl.git
Cloning into 'LeafletJS.jl'...
remote: Enumerating objects: 59, done.
remote: Total 59 (delta 0), reused 0 (delta 0), pack-reused 59
Receiving objects: 100% (59/59), 14.83 KiB | 197.00 KiB/s, done.
Resolving deltas: 100% (22/22), done.
$ julia
(#v1.5) pkg> generate LeafletJS
Generating project LeafletJS:
LeafletJS/Project.toml
LeafletJS/src/LeafletJS.jl
$ cp -r LeafletJS.jl/* LeafletJS/.
$ cd LeafletJS
LeafletJS $ julia
(#v1.5) pkg> dev .
[ Info: Resolving package identifier `.` as a directory at `/tmp/jl_temp/LeafletJS/`.
Path `.` exists and looks like the correct package. Using existing path.
Resolving package versions...
Updating `~/.julia/environments/v1.5/Project.toml`
[b1ddfcb9] + LeafletJS v0.1.0 `../../../../../tmp/jl_temp/LeafletJS`
Updating `~/.julia/environments/v1.5/Manifest.toml`
[b1ddfcb9] + LeafletJS v0.1.0 `../../../../../tmp/jl_temp/LeafletJS`

Related

What's the difference between using "devtools::install_github" and cloning a GitHub repository?

I used devtools::install_github... in R to install a repository and also installed the repository by using git clone in terminal. What's the difference between these two routes? So far, I understand that I can then use library(package) in R and will load the package in, whereas when I've cloned the GitHub repository, I don't think the package is immediately available. Can anyone explain the difference between these two methods?
Thanks!
git clone is a general way to check out a local copy of any git repository. It doesn't know about R at all or how R packages work. The devtools::install_github() (which is really just remotes::install_github()) checks out a copy of a repository and then does the extra work of actually building and installing the package so R can use it. Also it removes the local copy of the raw source files after it installs. If you just want to run/use the package, use remotes::install_github(). If you want to edit/contribute to the source code for a package, then use git clone to get the code.
devtools::install_github is an R function that attempts to install a package directly from GitHub repositories (Link to Documentation). This allows to install packages automatically from GitHub. You can specify multiple repositories in a single call to the function like this (Example from the previous link that attempts to install multiple repositories):
install_github(c("rstudio/httpuv", "rstudio/shiny"))
git clone is a console command that clones a git repository, by copying all the files (Link to Documentation). You only can clone one repository by command, and you may need to build and install the package after cloning it. Also, you can clone from hosts different to GitHub, like BitBucket, GitLab, or a custom git server. You can clone a repository like this (Example from the previous link that attempts to clone a repository from a host different to GitHub):
git clone git://git.kernel.org/pub/scm/.../linux.git my-linux

Buildroot > 2019.2: How to fix qt5virtualkeyboard install fail?

So I'm trying to upgrade an old buildroot system, from 2018.08.x to the latest release. The issue is that upgrading from 2019.2.x to 2019.5.x or 2019.8.x generates an error while installing qt5virtualkeyboard 5.12.2.
Note: after revision 2019.2.x the Qt kits are updated from 5.11 to 5.12.
I've checked the package install.mk but there are no changes in the related lines:
ifdef QT5VIRTUALKEYBOARD_3RDPARTY_PARTS
define QT5VIRTUALKEYBOARD_INSTALL_TARGET_3RDPARTY_PARTS
cp -dpfr $(STAGING_DIR)/usr/qtvirtualkeyboard $(TARGET_DIR)/usr
endef
endif
and I've already tested that cleaning the qt5virtualkeyboard->language layouts and the qt5virtualkeyboard->handwriting resolve the issue.
Here's the make output from revision 2019.5.x:
qt5virtualkeyboard 5.12.2 Installing to target
mkdir -p /home/fg/work/acto/buildroot/output/target/usr/lib/qt/plugins/platforminputcontexts
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/qt/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so /home/fg/work/acto/buildroot/output/target/usr/lib/qt/plugins/platforminputcontexts
cp -dpf /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libQt5VirtualKeyboard*.so.* /home/fg/work/acto/buildroot/output/target/usr/lib
mkdir -p /home/fg/work/acto/buildroot/output/target/usr/qml/QtQuick
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qml/QtQuick/VirtualKeyboard /home/fg/work/acto/buildroot/output/target/usr/qml/QtQuick/
cp -dpfr /home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qtvirtualkeyboard /home/fg/work/acto/buildroot/output/target/usr
cp: cannot stat '/home/fg/work/acto/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/qtvirtualkeyboard': No such file or directory
package/pkg-generic.mk:331: recipe for target '/home/fg/work/acto/buildroot/output/build/qt5virtualkeyboard-5.12.2/.stamp_target_installed' failed
make: *** [/home/fg/work/acto/buildroot/output/build/qt5virtualkeyboard-5.12.2/.stamp_target_installed] Error 1
At the moment I disabled the virtual keyboard configs to work on the system. But I would like to go deeper: I would like to understand if, during the update process, something went wrong, if I need to add some new dependencies packages or if this might be a package installation error.

Can I install a .deb during a BitBake Build?

Problem Definition
I'm attempting to adapt these rosjava installation instructions so that I can include rosjava on a target image built by the BitBake build system. I'm using the jethro branch of Poky.
Implementation Attempt: Build From .deb with package_deb.bbclass
According to the installation instructions, all that really needs to be done to install rosjava is the following:
sudo apt-get install ros-indigo-rosjava
Which works perfectly fine on my build machine. I figured that if I can just point to a .deb and use the Poky metadata class package_deb, it would do all the heavy lifting for me, so I produced the following simple recipe adapted on this posting on the Yocto Project mailing list:
inherit package_deb
SRC_URI = "http://packages.ros.org/ros/ubuntu/pool/main/r/ros-indigo-rosjava/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb"
SRC_URI[md5sum] = "2020ccc8b4a67dd918a9a2c426eece0b"
SRC_URI[sha256sum] = "ab9493fabe1285b0d21aab031348d0d733d116b0b2470bae90025709b303b649"
The relevant part of the errors I get during the above recipe's do_unpack are:
| no entry data.tar.gz in archive
|
| gzip: stdin: unexpected end of file
| tar: This does not look like a tar archive
| tar: Exiting with failure status due to previous errors
| DEBUG: Python function base_do_unpack finished
| DEBUG: Python function do_unpack finished
The following command produces the output below:
$ ar t python-rosdistro_0.4.5-1_all.deb
debian-binary
control.tar.gz
data.tar.xz
You can see here that there's a data.tar.xz, not data.tar.gz. What can I do to remedy this error and install from this particular .deb?
I've included package_deb in my PACKAGE_CLASSES variable and package-management in my IMAGE_FEATURES. I've tried other methods of installation which have all failed; I thought this method in particular would be very useful to know how to implement.
Update - 3/22
I'm attempting to circumvent the problems with the method above by doing my installation through a ROOTFS_POSTPROCESS_COMMAND which I've adapted from forum posts like this
install_rosjava() {
${STAGING_BINDIR_NATIVE}/dpkg \
--root=${IMAGE_ROOTFS}/ \
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ \
-L /var/cache/apt/archives/ros-indigo-rosjava_0.2.1-0trusty-20160207-031808-0800_amd64.deb
}
ROOTFS_POSTPROCESS_COMMAND += " install_rosjava() ; "
However, this fails due to dpkg not being a command found within the ${STAGING_BINDIR_NATIVE} path. The Yocto Project Reference Manual states that:
STAGING_BINDIR_NATIVE Specifies the path to the /usr/bin subdirectory of the sysroot directory for the build host.
Taking a look inside this directory yields a lot of commands but not dpkg (The recipe depends on the dpkg package, and this command can be found in my target rootfs after the build is finished; I've also tried pointing to ${IMAGE_ROOTFS}/usr/bin/dpkg which yields the same results). From what I understand of the BitBake process, this command may be in another sysroot, but I must admit that this is where my understanding breaks down.
Can I adjust this method so that it works, or will I need to start from scratch on an installation from source?
Perhaps there's a different method entirely which I could consider?
If you really want to install their deb directly then your rootfs postprocess is one solution. It doesn't work because depending on dpkg will build you a dpkg for the target but you want a dpkg that will run on the host. Add a dependency on dpkg-native to your image.
Though personally I'd either inherit bin_package and extract the deb they provide then re-package it as a standard package in OE, or ideally write a proper recipe to build rosjava and submit it to meta-ros (https://github.com/bmwcarit/meta-ros).
package_deb is where the packaging machinery for deb packages is stored, it's not something you'd inherit in a recipe but should be listed in PACKAGE_CLASSES.
When you put a .deb in a SRC_URI the fetcher will try to unpack it so you can access the contents: the assumption is that you're going to repack the contents as a native Yocto recipe.
If that's what you want to do then first you'll need to fix the unpack logic (in bitbake/lib/bb/fetch2/__init__.py) to handle .debs with xz-compressed data. This is a bug in bitbake and a bug report and/or patch would be appreciated.
The alternative would be to use their deb directly but I don't recommend that as it's likely the dependencies don't match. The best long-term solution would be to build it from source directly instead of attempting to use a package for another distro.

Maintaining a local repository for both Windows and Linux

I have some R code that I'd like to share with other people in my office, and also run periodically on our servers. We all have Windows 7 desktops, and the servers run Red Hat Enterprise Linux.
I've been through the docs, and I'm stuck. None of the following have all the necessary steps, detail the correct folder structure, or tell me how to build a Linux package, or build a Windows package on Linux.
http://cran.r-project.org/doc/contrib/Leisch-CreatingPackages.pdf
http://cran.r-project.org/doc/manuals/R-admin.html#Setting-up-a-package-repository
Creating a local R package repository
So I have my code in git.
$ mkdir ~/daveStuff
$ cd ~/daveStuff
$ git init
$ git remote add origin git#davez0r.co:/opt/git/daveStuff.git
$ git pull origin master
Now in my home directory I have this folder structure:
daveStuff
|-- DESCRIPTION
|-- R
|-- stuff.R
|-- exec
|-- script.R
My description file looks like this:
Package: daveStuff
Type: Package
Title: What the package does (short line)
Version: 1.0
Date: 2014-02-03
Author: Who wrote it
Maintainer: Who to complain to <yourfault#somewhere.net>
Description: More about what it does (maybe more than one line)
License: What license is it under?
I'm running apache on one of my servers. So I added this:
/var/www/html/R/src/contrib/3.0/
This correctly maps to the following, where I read any files I put there:
http://davez0r.co/R/src/contrib/3.0/
What I'd like to be able to do is the following, from either Windows or Linux:
> install.packages("daveStuff", repos="http://davez0r.co/R", type="source")
> library(daveStuff)
So first step is that I need to turn my library into a package.
$ cd ~ # one under the "daveStuff" directory
$ R CMD build daveStuff
This creates a zip file:
~/daveStuff_1.0.tar.gz
Now I copy that file to my repository location:
$ cp ~/daveStuff_1.0.tar.gz /var/www/html/R/src/contrib/3.0/
Now if I go like this:
> install.packages("daveStuff", repos="http://davez0r.co/R", type="source")
Warning in install.packages :
unable to access index for repository http://davez0r.co/R/src/contrib
It gives me that error message saying that it can't find the package. So I create a package manifest:
$ cd /var/www/html/R/src/contrib # one under where I put the archive
$ Rscript -e 'tools::write_PACKAGES(".", type="source", subdirs=TRUE)'
This gives me a PACKAGES file:
Package: daveStuff
Version: 1.0
MD5sum: 817bbfedeb218ce0331dd7108408c5e6
NeedsCompilation: no
Path: ./3.0
Now it works when I try to load it:
> install.packages("daveStuff", repos="http://davez0r.co/R", type="source")
Unresolved issues:
I've lost the scripts that were in the exec directory.
Should I wrap these in functions and include them in the library?
Should I stick with source packages?
How do I make Windows binary packages on Linux?
It seems to me that you skipped one final step.
One needs
A local package (which you have)
Tarballs for Linux and binary packages for Windows (not sure)
A local repository (which you started)
Meta-data on your repository (which you seem to miss)
I do that at work for similar setup (some Windows, lots of Linux) via a simple script:
#!/bin/bash
## see e.g.
## http://cran.r-project.org/doc/manuals/R-admin.html\
## #Setting-up-a-package-repository
## http://stackoverflow.com/questions/2905650/creating-a-local-cran-repository
ver=3.00
rsync -vu *tar.gz /SomeServer/R/src/contrib/
rsync -vu *zip /SomeServer/R/bin/windows/contrib/${ver}/
cd /SomeServer/R/src/contrib/
r -e 'tools::write_PACKAGES(".", type="source")'
cd /SomeServer/R/bin/windows/contrib/${ver}/
r -e 'tools::write_PACKAGES(".", type="win.binary")'
I use littler's r binary here, you could equally well use Rscript.

`mrt add` throws unknown error when installing Atmosphere packages with Vagrant on Windows

Using Vagrant ssh on Windows 7, mrt add scss (as an example) displays the following in the console:
vagrant#vagrant:/vagrant/MyMeteorApp$ mrt add scss
scss
tag: https://github.com/fourseven/meteor-scss.git#v0.5.1.1
fs.js:730
return binding.symlink(preprocessSymlinkDestination(destination, type),
^
Error: UNKNOWN, unknown error '/vagrant/MyMeteorApp/packages/scss'
at Object.fs.symlinkSync (fs.js:730:18)
at /usr/local/lib/node_modules/meteorite/lib/dependencies/package.js:129:10
at /usr/local/lib/node_modules/meteorite/lib/sources/git.js:75:15
at ProxyWriter.<anonymous> (/usr/local/lib/node_modules/meteorite/lib.souces/git.js:138:5)
at DirWriter.EventEmitter.emit (events.js:92:17)
at end (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:323:12)
at /usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:313:32
at endUtimes (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:239:48
at setProps (/usr/local/lib/node_modules/meteorite/node_modules/fstream/lib/writer.js:296:5)
The same error is displayed when attempting to install any Atmosphere package the first time. The command does update "packages" in smart.json:
"packages": {
"scss": {}
}
Whenever mrt is run again, the console displays smart.json changed.. installing from smart.json and hangs.
I did find the package at /home/vagrant/.meteorite/packages/scss but it is nowhere else.
My environment was set up using the Vagrant Chef provisioning. Node is version 0.10.10. The OS is Ubuntu. I have tried reinstalling meteorite using the -H command. Any help is appreciated, I've been trying to get this to work for two days now.
I think that's the problem. Meteorite 0.6.0 uses symlinks but Windows can't handle it. Try copying the sass folder into packages instead of making them symlinks.
Some packages you will need to copy with cp -rL

Resources