How to modify an installed gem on Windows? - ruby

So I've installed svn2git using Ruby on Windows. Unfortunately, since git has made the change of Master branch to Main, this has broken the script. I've found the script in
C:\Ruby27-x64\lib\ruby\gems\2.7.0\gems\svn2git-2.4.0
and made the required modifications. How do I recompile / remake this so that when I run svn2git on the command line it uses my modified script?

since git has made the change of Master branch to Main, this has broken the script
I'm not sure what you mean by "broken"; perhaps you needed to rename master-->main here? (Or even better, you could make it somehow configurable, not hardcoded?)
How do I recompile / remake
This is ruby. It's an interpreted language; you don't need to compile anything.
It would be "bad practice" to edit the gem directly on your machine, but this should still work. If you run svn2git on the command line right now, then - assuming that's the correct installation (e.g. you don't also have a ruby 2.6 version installed that's getting picked up?!), it should run your modified code instead.
But for a "better" long-term solution, it would be advisable to fork the project, make your change, and install your own version of the project.
You could also open a pull request with your change, in case the original author is still active and willing to release an update.

Related

Install package with pip that has additional qualifiers

Our CI pipeline publishes wheels for branches that have a version of
<base version>-dev<timestamp>+<branch name>.p<pipeline id>
So if I am working on cool-stuff on in the xyzzy branch, it might upload a wheel for version 1.2.3.dev202211221111+xyzzy.p1234
Somebody else, working in the foobar branch, might cause 1.2.3.dev202211221115+foobar.p1235 to be created.
How can I get pip to install the latest version from the xyzzy branch? I tried pip install cool-stuff>1.2.3.dev*+xyzzy but it complained that it could not find a matching version (even though the available versions that it listed included a +xyzzy tag.)
pip install cool-stuff==1.2.3.dev202211221111+xyzzy.p1234 did work, but I would prefer not have have to update the time stamp and pipeline number each time. I am hoping to put cool-stuff >= <magic> in my config file and just run pip install -e . whenever I need new dependencies.
What format do I need to use here?
As far as I know, it is not possible. I can not think of a workable solution that would be based on the version string only. The "local" part of the version string (in other words the part after the plus sign +) can not be used to differentiate between two releases as you intend to.
If I were in your situation, I think I would investigate a solution where the CI/CD pipelines generate distributions with a name customized according to the git branch. For example in your case the pipelines should generate wheels for Library-foobar or Library-xyzzy, depending on what branch is currently being worked on (while still keeping the same top-level import names of course). This assumes that you can customize your pipelines and processes deeply enough to support such a workflow.

How to build own v8 fork

I have my own fork of v8 and would like to build it.
However, gn and gclient keep failing and telling me that I need to be inside a checkout.
$> git clone <ownRepository>
$> gn gen out/build
gn.py: Could not find checkout in any parent of the current path.
This must be run inside a checkout.
``
How can I build my own fork? `fetch` does not seem to accept custom repositories.
The V8 git repository (or a fork of it) simply doesn't contain everything that's required for building; in particular it misses third-party dependencies and shared build configuration logic. The purpose of the official build tools/workflow is to set all that up. So the easiest path forward for you is probably to get a regular V8 checkout (using fetch v8), and then replacing the v8 directory in there with your own. Make sure that the versions match (at least approximately).
The alternative is to figure out what fetch v8, gclient sync and gclient runhooks do, and doing all of that by hand -- totally possible, as they're all just scripts and entirely open source, but it's a lot of work and not much fun, so I wouldn't recommend that.

How to install golang-libguestfs package?

I am trying to install the libguestfs package for golang but couldn't find the way to do so. I went through this but it didn't work for me and I believe it's empty. I see only test files here
Following is the content of the README
$GOPATH
-------
http://golang.org/doc/code.html
Note that $GOPATH is set (by the ./run script) to the
libguestfs/golang directory so that "installs" happen in the local
build tree.
From this I could figure out that I need to build the package but again for that, I couldn't find some help or proper document.
Is there any way to do the installation? I am using RHEL 7.7
Libguestfs (the C library) is packaged already in RHEL 7, so I would suggest first of all installing that using yum install libguestfs. That's the version that Red Hat supports.
We don't ship the golang bindings, not even in RHEL 8. Furthermore the bindings in all languages are generated from a mechanical description of the API and thus not stored directly inside our git repository. That's why you could only find test files in git.
However we do distribute the generated files in the tarballs, so an easy way is to grab the latest tarball from https://download.libguestfs.org/1.42-stable/ and look in the golang/src/libguestfs.org/guestfs subdirectory of the tarball.
The harder way is to generate them from git. These steps worked for me on RHEL 7.7, YMMV:
sudo yum-builddep libguestfs
git clone https://github.com/libguestfs/libguestfs
cd libguestfs
git submodule init
git submodule update
./bootstrap
./autogen.sh SUPERMIN=/usr/bin/supermin5
make
and again look in the golang/ subdirectory.
I'm reasonably sure that golang bindings from one version should work with another version of the C library. We did test this at one point in time, so if it's no longer true then it may have regressed as these things sometimes do.

How to enforce bundle install location

I come from a Python and JavaScript background.
When developing a JavaScript project, dependencies are installed in a node_modules directory in the project root.
When developing Python project, typically virtualenvwrapper is used. In this case dependencies are installed in a virtual environment, which is located in ~/.virtualenvs/<project_name> by default.
Now I need to use a ruby tool for a project. The tool that appears to be the most promising for a similar setup as described above, is bundler.
However, the default installation location for bundler is system-wide. I consider this to be harmful.
For one of my systems, it will prompt for a password, at which point I can still abort.
However, for my other system I can write into the global ruby installation. I'm using a homebrew installed ruby here. Bundle will just install dependencies globally.
I know I can specify the installation location by adding --path, but this is easy to forget.
One way to enforce an installation path is by committing .bundle/config. It would just have to contain this:
---
BUNDLE_PATH: "."
However, some googling around shows that it's not adviced to commit this file.
What is the recommended way to prevent accidental global installations using bundler?
Who's to say it will be accidental? It really depends on what context you're talking about here. I have my Ruby set up so that bundle install works without requiring sudo, it's all done through rbenv automatically. The same is true with rvm if done as a user-level install.
When it comes to deploying apps and you want to make sure it's deployed correctly, that's where tools like Capistrano come into play: Create a deployment script that will apply the correct procedure every time.
Checking in a .bundle/config is really rude from a dev perspective, just like checking in any other user-specific preferences you might have. It causes no end of conflict with other team members.

After updating Git Bash on Windows, still shows older version

On Git Bash's download site, it says you can clone it to update it. I downloaded it to install it, but I am starting to really get into Git and would like to clone it every time I want to update it from now on. I think I found the place where we need to clone it to, after much searching & less documentation than usual. If I am right, it is in the home directory, right under my nose the whole time!
I checked the version number with git --version beforehand, then cloned in that directory, then rechecked the version number Both times it said git version 1.8.3.msysgit.0, but on the download site it says the latest version is 1.8.4.3.
Have I not found the elusive git folder, or does the Git Bash team not let you directly clone the latest version until some time after it comes out? I know VirtualBox does that, for example.
I know this is sort of a duplicate of this question, but I tried its answer & the PATH variable didn't even have Git!
I would recommend to not try to update it, but simply download the portable version of msysgit and unzip it in a dedicated folder, that you then add to your path:
Current Portable msysgit download.
=> I unzip the latest one in (for instance) C:\prgs\git\PortableGit-1.8.4-preview20130916.
=> I add 'c:\prgs\git\PortableGit-1.8.4-preview20130916\bin' to my PATH.
Now if you want to automate that download/update process, I am building a Powershell script which does just that (for git and 30 other programs, including Mercurial, Subversion, but also Python, Ruby, Go, ...):
senv: download the zip archive of senv, unzip it in a path and call:
senv
The first time, you specify where you want all those programs to be downloaded: those are portable software only: no registry modification, no system variables modified.
If you don't want one of those program anymore, simply delete their installation folder.
That's it.
But each time you will call senv -u, it will check their respective web page and, if a new version is detected, it will download/upzip said new version in its dedicated folder, without removing the previous one.

Resources