When using node.js we have npx - a tool that makes it easy for users to install and manage applications (especially CLI tools) rather than libraries. For Python there is pipx. Is there a tool for OCaml that offers the same functionality?
pipx run "$APP" --example foo" install & update & run all-in-one
Apps are installed into isolated environments so that they do not step on each other's toes. (e.g. incompatible dependency requirements)
I know there is one general-purpose option - Docker, but is there anything tailored to OCaml?
Edit: the main reason I dislike Docker is that it alters my view of the filesystem. A CLI tool might accept paths via the arguments, the environment and config files and then open them. Reading relative to CWD is also common. If a CLI tool is distributed via Docker, the user has to be aware of the altered filesystem view, which adds cognitive overhead.
If you browse the list of OPAM packages, you will see not only libraries, but also applications. A few examples from a quick perusal:
dune
dumpast
utop
xe
Related
I am trying to install/add manually the *.jl-master.zip files, I am doing this because I have a computer without access to internet but I don't know how to do the offline installation.
The version of Julia is 1.3.0 and the O.S. Windows 10
I had tried this,
Instruction I followed
but for me It does not work.
Thanks
Regards
Installing Julia packages offline is very difficult due to the fact how binary dependencies work.
You have basically two options:
buying JuliaTeam/JuliaPro from Julia Computing (maybe someone who is using it will ever see that thread and could share their experience?)
hacking
Regarding the second option the best bet is to install all required packages on a different machine having and copy the .julia folder to your offline machine (or, depending on your configuration folder referenced by the JULIA_DEPOT_PATH system environment variable).
However, in most cases you will need to rebuild several packages. The problem is that Julia packages have several binary dependencies that come from different sources. This problem has been noted by the Julia community and is being addressed by the Julia Artifacts mechanism.
Today the most common step is to manually edit deps/build.jl file in each Julia package that is downloading binary resources in its build process and make the build code to point to files in your local repository. Once done you can rebuild the package offline by running using Pkg;Pkg.build("PackageName").
Can nix be used in a continuous-delivery workflow?
We're using semaphore as our continuous integration service, and now I'm looking into building packages upon a successful build. For this I'm considering using nix.
I don't know what would be the right way of setting up a continuous delivery pipeline with this package manager. It seems that such an automated process would involve:
Making a branch of the nixpkgs repository (in the CI server).
Updating the rev field of fetchFromGithub.
(automatically) submitting a pull-request.
But I don't know if this makes sense, and also I'm concerned that the continuous-delivery process involved a manual step (having an human aproving the pull-request).
Can nix be used in a continuous-delivery workflow?
Yes. It's typically done with Hydra, a CI system built with Nix. But, it may be possible to do this with Semaphore.
Semaphore CI provides build environments that are language specific, but... it's running Ubuntu, so theoretically you can do something like this:
Install Nix as if it were a dependency. See this article.
Add your Nix package, which I suppose you can do with Git. You don't really need to clone Nixpkgs.
Use nix-build to build your package. This will create a result symbolic link to the build output.
Deploy using git-deploy.
If you do something like this with your package you can call it directly from nix-build because you won't have to provide the package dependencies as arguments:
{ pkgs ? import <nixpkgs> {} }:
let
stdenv = pkgs.stdenv;
...
in
stdenv.mkDerivation {
..
}
Optimization
Installing Nix for every build is wasteful, but perhaps you can cache the Nix store. See this article.
I would like to override the default powershell scripts that come with win_chocolatey module of Ansible. How do I do that?
In my case, I am trying to override the ChocolateyInstall.ps1 that comes with MsSqlServerManagementStudio2014Express. I would like to pass a few more parameters such as system administrator password and instance names during the silent installation of MsSQLServer.
I have tried giving these additional parameters with "install_args" and "params" options in win_chocolatey module call in my ansible playbook. But there are no handlers written in MsSqlServerManagementStudio2014Express's powershell scripts to include them during silent installation.
Package Parameters vs Install Arguments
Install Arguments (--install-arguments option for choco.exe) are completely invisible to the packaging, and they are appended to the current set of silent arguments in the package. One can also override them completely with --override-arguments. In the commercial editions of Chocolatey, you can also pass --install-arguments-sensitive to keep secrets out of logs.
Package Parameters (--package-parameters|--params) are different, can be used with anything related to packaging (not just for the installer), but must also be present in the packaging itself. For commercial editions and secrets, you also have --package-parameters-sensitive.
Option 1: Community Repository Packages
You would need to ensure that the package is using Install-ChocolateyPackage, Install-ChocolateyInstallPackage, or other built-in methods to know that install arguments can be used with the package. If you need parameters, you will need to work with the maintainers of the package to get those implemented.
Option 2: Use Your Own Packages
If you are using Chocolatey in an organization, you will want to use your own package you store somewhere internally. That guarantees much more reliability and repeatability, something that is instrumental to organizational use of anything.
Plus you can bake installers directly into the package as you are not subject to distribution rights internally, providing an even more reliable experience.
It is especially helpful to read over and understand this when planning for Chocolatey in an organization: https://chocolatey.org/docs/community-packages-disclaimer
The task: Run a tensorflow train.py script I wrote in the cloud with at least 32GB of memory.
Requirements: The script has some dependencies like numpy, scipy, and mkt. I need to be able to install these. I just want a no-nonsense ssh shell like experience. I want to put all my files including the training data in a directory, pip install the packages if necessary, then just hit python train.py and let it run. I'm not looking to run a web app or have Google's machine learning platform do it for me.
All the tutorials around seem needlessly complicated, like they're meant for scaled deployments with http requests and all that. I'm looking for a simple way to run code on a server since my computer is too weak for machine learning.
Don't use AppEngine -- use Compute Engine instead. Almost the same thing, but very simple and you are completely in control of what you run, what you install etc.
Simple steps that should work for you:
-Create a Compute Engine instance
-Chose operating system (Ubuntu xx, but you can choose others instead)
-Chose how many CPUs and how much memory you want (select Customize in order to set yourself the CPU/memory ratio rather than getting default options)
-Enable HTTP/HTTPs in order to be able to use Tensorboard later
-Once created, SSH into the machine. Python is already pre-installed (2.7 default, but 3.x also available as Python3 alias)
-Install Tensorflow, Numpy, Pandas, and whatever you want with simple PIP
-You can also install Bazel if you want to build Tensorflow from source and to speed up the CPU operations
-Install gcsfuse if you want to copy/paste stuff quickly from cloud storage buckets
-Use tmux if you want to run several Tensorflow sessions in parallel (i.e.to try different hyperparameters/etc.)
This is all very clean and simple and works really well. Don't forget to shut it down after finished. You can also create a Preemptable instance to make it super-cheap (but it can be shut down at any time without warning, but happens rarely).
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.