I was surprised not to see a plugin for semantic-release to do replacing of strings (e.g., by regex) within files, e.g., to update the version string in a service-worker (as well as README).
Does semantic-release have such a feature or plugin?
There is no official plugin to do that.
You can use a npm script or #semantic-release/exec to run a script that do the replacement during the prepare step.
See How can I use a npm build script that requires the package.json’s version ?.
Related
Meson/Ninja provide an easy method to run a script at install time.
For example, this line will tell Meson to run the glib-compile-schemas command to compile the GSettings on Linux (system configuration options).
meson.add_install_script('glib-compile-schemas', schemas_dir)
(this command will be automatically run when the user executes ninja install)
How can I tell Meson to run a custom command at uninstall?
In this specific case I would like to delete (or at least reset to default) the key-value pairs in GSettings. To reset them, I have found that the command is gsettings reset-recursively <path> (successfully tested in terminal).
Adding custom uninstall script is still being discussed, it's proposed quite some time ago but not yet implemented. It looks this task is typically left for package manager (and therefore to corresponding packaged scripts).
But I agree, there is some illogical asymmetry in case of meson install command. As a workaround, you can create your own target:
run_target('my-uninstall', command : ['scripts/uninstall.sh'])
The drawbacks, of course, are that it should be invoked explicitly, cannot override, append or rename internal uninstall target and script should have executable permissions.
The internal, reserved uninstall target, however, does revert all explicit install operations:
Meson allows you to uninstall an install step by invoking the
uninstall target. This will remove all files installed as part of
install. Note that this does not restore the original files. This also
does not undo changes done by custom install scripts (because they can
do arbitrary install operations).
I am really new to Julia and confused about using an old version of the SISL Vec package.
I am trying to setup ngsim_env and their instructions require you to use an older v0.1.0 of Vec. But, when I followed the instructions to install the Vec package and then checkout the v0.1.0 tag it didn't work.
Here's what I did
$ julia ../build.jl for some package which includes this block
packages = keys(Pkg.installed())
if !in("Vec", packages)
Pkg.clone("https://github.com/tawheeler/Vec.jl.git")
end
Note: This git URL actually goes to the SISL Vec page.
cd ~/.julia/packages/Vec
git fetch tags
git checkout v0.1.0
I did a bunch of other installations with many other packages. At some point I noticed that there is a package ~/.julia/dev/Vec and ~/.julia/packages/Vec. The one in dev has the correct v0.1.0 code and the one in packages has the newer wrong code. When I tried to use other packages that needed the older Vec they were throwing errors and the paths were to files in the packages directory.
I tried Pkg.rm("Vec"). This did something to the project manifest. After nothing worked, every package would throw errors like KeyError: key "Vec" not found and Pkg.add("Vec") nor original Vec installation helped. I even tried removing both the Vec directories from ~/.julia but that didn't help.
I guess a big question is why does Julia put some packages into packages/ and others into dev/ and how to control which one's get used if the same package appears in both places like Vec is.
Would greatly appreciate any assistance, totally confused.
The dev command fetches a full clone of the package to ~/.julia/dev/
via the docs. The only things I have in my dev directory there are the ones I am developing on my own.
I think that triggered when you did a check out manually with git checkout.
Accordingly:
to stop tracking a path and use the registered version again, use free
Try deleting the packages, and whipping mentions of Vec.jl from your manifest:
(v1.0) pkg> rm Vec
(v1.0) pkg> add https://github.com/tawheeler/Vec.jl.git#0.1.0
In general, try using Pkg when possible, cause it does a lot of house keeping magic in the back
(Also, the repl interface with pkg makes everything easier, so hit ] from a blank julia> to get there. And a quick Pkg.status() or ] st will show you what youre tracking and whats in dev and what version you have pinned, etc.)
On windows after running the grunt build command for creating brackets shell it gives done without errors but i dont see any .exe file generated..
What might be the problem???
Here are some possible solutions:
Are you following the full brackets-shell build instructions, including all prerequisites?
Make sure Brackets isn't running at the same time. The build will fail silently if the .exe file is currently in use (see bug).
Try with a fresh git clone of the repo. If your brackets-shell local copy has been around for a while, sometimes the build & deps folders can get in a bad state. (I'm assuming you haven't modified the source at all. If you have, try with an unmodified copy of the source first to make sure it builds correctly without any of your changes).
Check that python --version shows 2.7.x
Verbose build output would also be helpful in diagnosing issues like this, but unfortunately there's not yet an easy way to get that...
If you follow the instructions on bracket-shell's wiki page, the Windows executable should be created in the Release directory.
I just installed clean-css (https://github.com/GoalSmashers/clean-css) via npm command line and I would like to use it to concatenate and minify some css files (duh). However, I am getting this error:
'cleancss' is not a recognized as an internal or external command, operable program or batch file.
I am new to doing things from the command line so this completely throws me for a loop. I couldn't find an answer to this clean-css specific issue. The general answer for this type of error seems to be that the environment variables need to by updated but while I have done that in the past to point to certain executable files I am not sure what I would have to do in this particular scenario. Any takers?
Try installing in with
npm install -g clean-css
Using the global option should make it available in your shell.
I was experiencing this problem and, as of 4.0, clean-css-cli needs to be installed. I take no credit I merely found the answer here:
https://stackoverflow.com/a/41912485
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)