How to update a proprietary dependency installed from Git repo with Yarn 3?
package.json entry:
"#foo/utils": "git+https://gitlab+deploy-token-...:...#gitlab.com/foo/bar.git#ISSUE-6652-some-git-branch",
yarn up #foo/utils results in the following error:
➤ YN0027: #foo/utils#git+https://gitlab+deploy-token-...:...#gitlab.com/foo/bar.git#ISSUE-6652-some-git-branch can't be resolved to a satisfying range
Internal Error: The remote server failed to provide the requested resource
I need to update the package to latest commit in that branch and the only way I currently know is removing entry for this package manually from yarn.lock, but I guess that's not how things should be done.
It's not ideal since it's interactive, but you can run yarn up -i #foo/utils and choose "reuse" to force the package to resolve (and reinstall) from the same git source again.
Related
Since yesterday's update on VSO / VSTS (17 Aug update) our gulp tasks fail.
The failing part is where we overwrite existing files using gulp.dest() in a gulp build step.
I've tried to delete the file first and then use gulp.dest and this works, however this practice can't be used on all places because we need to inject code into existing files.
We use Gulp version 3.9.0
Error: EPERM: operation not permitted, open 'C:\a\1\s\Source\Project\Project.Web\index.cshtml'
Since the last update of VSO all source files are now readonly. We solved our issue by removing the readonly flag on the source files.
Based on my test, the issue is related to Gulp 3.9.0, I can reproduce that issue with Gulp 3.9.0 (npm install task, Command: install, Arguments: gulp#3.9.0), the Gulp 3.9.1 works fine. So you can update to gulp 3.9.1.
You could add npm install task to install latest version. (Command: install; Argument: gulp)
Trying to install Bolt v2.2.4 with the following commands:
git clone git://github.com/bolt/bolt.git bolt
cd bolt
git checkout v2.2.4
composer install
Then I get the following error:
$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for m6web/symfony2-coding-standard dev-master#dev -> satisfiable by m6web/symfony2-coding-standard[dev-master].
- m6web/symfony2-coding-standard dev-master requires squizlabs/php_codesniffer ~1.0 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
I just ran into the same issue under bolt 2.1.9
I 'fixed' it for me for the moment by changing 1.5.* to ~2 for squizlabs/php_codesniffer in composer.json
Are you on IPv6 per chance? If so, do a composer self-update.
Waiting for yum...
One of the configured repositories failed (Fedora 21 - x86_64),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Disable the repository, so yum won't use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
--enablerepo for temporary usage:
yum-config-manager --disable fedora-21
4. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=fedora-21.skip_if_unavailable=true
Cannot retrieve metalink for repository: fedora-21/x86_64. Please verify its path and try again
error: Child process exited with code 1
I'v made a static single page site using grunt. I'm now trying to deploy it to heroku using the heroku-buildpack-nodejs-grunt for node grunt.
Below is a pic of my root directory:
Here's my Gruntfile package.json:
Procfile:
web: node index.html
When I run $ git push heroku master it gets to the Gruntfile and fails:
-----> Found Gruntfile, running grunt heroku:production task
>> Local Npm module "grunt-contrib-uglify" not found. Is it installed?
The above errors proceed to list all local NPM modules as not found. If I list all loadNpmTasks instead of using "load-grunt-tasks", I get the exact same error.
When I $ heroku logs I get:
Starting process with command `node web.js`
Error: Cannot find module '/app/web.js'
Can anyone see where I've gone wrong?
For anyone passing by here, I wasn't able to solve the problem. This is where I got to:
In my Gruntfile, I moved npm modules from devDependencies to dependencies. Heroku was then able to install these dependencies.
However, when Heroku ran the tasks, it stops at the haml task w/ error "You need to have Ruby and Haml installed and in your PATH for this task to work". Adding ruby & haml to the Gruntfile as engines did not work.
The only thing I can think of is that maybe Heroku installs your devDependencies first, tries to run Grunt, but since it didn't install load-grunt-tasks yet, you don't get the grunt.loadNpmTasks( 'grunt-contrib-uglify' ); line (which load-grunt-tasks does for you), and thus Grunt can't find the package.
Can you try changing your Gruntfile to explicitly list out all npm modules using the grunt.loadNpmTasks() method?
EDIT:
Just remembered another thing I had to do:
heroku labs:enable user-env-compile -a myapp
heroku config:set NODE_ENV=production
(Obviously replacing myapp with your Heroku app name.)
This makes Heroku allow user set environment variables and then sets your server to production. Try that, and set your dependencies and devDependencies as you had them originally (just to see if it works).
I am coming pretty late to the game here but I have used a couple methods and thought I would share.
Option 1: Get Heroku to Build
This is not my favorite method because it can take a long time but here it is anyway.
Heroku runs npm install --production when it receives your pushed changes. This only installs the production dependencies.
You don't have to change your environment variables to install your dev dependencies. npm install has a --dev switch to allow you to do that.
npm install --dev
Heroku provides an article on how you can customize your build. Essentially, you can run the above command as a postinstall script in your package.json.
"scripts": {
"start": "node index.js",
"postinstall": "npm install --dev && grunt build"
}
I think this is cleaner than putting dev dependencies in my production section or changing the environment variables back and forth to get my dependencies to build.
Also, I don't use a Procfile. Heroku can run your application by calling npm start (at least it can now almost two years after the OP). So as long as you provide that script (as seen above) Heroku should be able to start your app.
As far as your ruby dependency, I haven't attempted to install a ruby gem in my node apps on Heroku but this SO answer suggests that you use multi buildpack.
Option 2: Deploy Your Dependencies
Some argue that having Heroku build your application is bad form. They suggest that you should push up all of your dependencies. If you are like me and hate the idea of checking in your node_modules directory then you could create a new branch where you force add the node_modules directory and then deploy that branch. In git this looks like:
git checkout -b deploy
git add -f node_modules/
git commit -m "heroku deploy"
git push heroku --force deploy:master
git checkout master
git branch -D deploy
You could obviously make this into a script so that you don't have to type that every time.
Option 3: Do It All Yourself
This is my new favorite way to deploy. Heroku has added support for slug deploys. The previous link is a good read and I highly recommend it. I do this in my automated build from Travis-CI. I have some custom scripts to tar my app and push the slug to Heroku and its fast.
I faced a similar problem with Heroku not installing all of my dependencies, while I had no issue locally. I fixed it by running
heroku config:set USE_NPM_INSTALL=true
into the path, where I deployed my project from. This instructs Heroku to install your dependencies using npm install instead of npm ci, which is the default! From Heroku dev center:
"Heroku uses the lockfiles, either the package-lock.json or yarn.lock, to install the expected dependency tree, so be sure to check those files into git to ensure the same dependency versions across environments. If you are using npm, Heroku will use npm ci to set up the build environment."
I need to install netcdf-openmpi-devel on Red Hat 6. The problem is that this is not provided by the repositories I have: redhat and epel. I already tried downloading several fedora rpms, but for almost all of them, it's not possible to verify their keys (doing rpm -K package). I was able to get one key for one of the rpms, but then it shows that I don't have the required dependencies like:
netcdf-openmpi, which is kind of what I am trying to install.
Is there another way to install this?
Thanks for your help!
The cleanest approach is to build an RPM package against the RHEL6 package set. This will make sure that all dependencies are satisfied. To do this, taking advantage of already existing packages, you can clone the Fedora netcdf package files from [1] and then build the package with mock, using rpmbuild (see [2]) or, actually better, mock (see [3]).
You might encounter the situation where a build dependency is not available in the rhel or epel repos. You can then again clone the respective package files from the Fedora git repository and build that package before.
So, to wrap up your steps might look something like this:
$ git clone git://pkgs.fedoraproject.org/netcdf.git
$ cd netcdf
## Look at netcdf.spec, make changes if necessary
## To build using rpmbuild (probably easier than mock)
# yum install rpmdevtools
$ rpmdev-setuptree
$ mv netcdf.spec $HOME/rpmbuild/SPEC
$ mv * $HOME/rpmbuild/SOURCES
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba netcdf.spec
## rpmbuild might complain about unsatisfied build dependencies. Install these as necessary, some build dependencies might not be available in the repos, you will need to build then following the same procedure.
One particular thing you'll need to be aware of is that there is a netcfd package available in epel, which however is built without openmpi support (see [4]). If you install your home-built rpm, you probably want to make sure that a possible update from the epel repositories won't override your home-built version (this happens if the epoch:version-release of the package in the repositories is newer than the one you've built). You could:
Monitor what will get updated, if a netcdf version from epel would update your home-built rpm, then grab the newest package sources from the Fedora git repo and build a new package.
Exclude netcdf* from epel by adding exclude=netcdf* to the epel repo file in /etc/yum.repos.d.
[1] http://pkgs.fedoraproject.org/cgit/netcdf.git/
[2] http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Preparing_your_system
[3] http://fedoraproject.org/wiki/Projects/Mock
[4] http://pkgs.fedoraproject.org/cgit/netcdf.git/tree/netcdf.spec?h=el6