When using yarn-berry, should I apply the unplugged to the git repository when implementing zero-installs? - yarn-v2

When using yarn-berry, should I apply the unplugged to the git repository when implementing zero-installs?
As far as I know, in the case of zero-installs, we proceed with yarn start immediately after receiving
git clone from the git repository.
However, because of the Unplugged Folder, we have to proceed with yarn installs inevitably.
Of course, there are ways to put UnpluggedFolder in git repository using git-ignore, but I'm not sure if this is the correct way to run zero-installs.
When I tried yarnstart
$ yarn start
C:\Users\com\Desktop\zero3\project\.pnp.cjs:25991
Error.captureStackTrace(firstError);
^
Error: Required unplugged package missing from disk. This may happen when switching branches without running unplugged packages must be fully materialized on disk to work).
Missing package: open#npm:8.4.0
Expected package location: C:\Users\com\Desktop\zero3\project\.yarn\unplugged\open-npm-8.4.0-df63cfe5dules\open\
gitignore
# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
# dependencies
/node_modules
# testing
/coverage
# production
/build
# misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.yarn/*
!.yarn/cache
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
# !.yarn/unplugged

Related

How to override bitbake file conflicts

Working on a couple of recipe's that have file conflicts with base packages.I am trying to figure out how to force override the conflicts. In particular I am overwriting the /etc/network/interfaces file with a custom one within my recipe. How do I tell bitbake that the file(s) in my package are to take precedence over the file(s) from the base packages?
I am using RPM as the package management subsystem with in the build environment.
Running transaction test
Error: Transaction check error:
file /etc/network/interfaces conflicts between attempted installs of router-1.0-r0.noarch and init-ifupdown-1.0-r7.qemuarm64
file /etc/udhcpc.d/50default conflicts between attempted installs of router-1.0-r0.noarch and busybox-udhcpc-1.24.1-r0.aarch64
You can't. Either don't install one of the packages in the conflict or override the original recipe's file with a bbappend.

Yarn 2 init, add failing

I'm experimenting with yarn 2 and faceplanting.
I created a new folder: /projects/yarn2/
As per their install guide https://yarnpkg.com/getting-started I ran
cd /projects/yarn2/
yarn set version berry
yarn init
then (as per their guide https://yarnpkg.com/getting-started/usage )
yarn add react
and got the following error:
Usage Error: The nearest package directory (/projects/yarn2) doesn't seem to be part of the project declared in /projects.
- If the project directory is right, it might be that you forgot to list yarn2 as a workspace.
- If it isn't, it's likely because you have a yarn.lock or package.json file there, confusing the project root detection.
$ yarn add [--json] [-E,--exact] [-T,--tilde] [-C,--caret] [-D,--dev] [-P,--peer] [-O,--optional] [--prefer-dev] [-i,--interactive] [--cached] ...
What am I doing wrong?
You either don't have package.json or yarn.lock which confuses yarn if the package is added in the workspace or not. Just run the following command and I think your problem must be solved.
cd <folder_name>/<project_name>
touch yarn.lock
yarn
Check to see if you have a package.json or yarn.lock file in your /projects directory. If you do, clear it/them out and this should start working.
To add to the previous answers what worked for me was:
It seems to be that yarn.lock file is what's really required, so if you have started with yarn v1.x and did yarn init - then you will have a package.json file in the project dir already.
If you now switch over to yarn v2 by doing yarn set berry, and want to add a package by yarn add [whatever] it will fail. You can work around that by creating an empty file by: touch yarn.lock (or on windows just cat '' > yarn.lock) after that it should work fine.
I figured out an even better / faster way to do it now, just do this in an empty project folder:
yarn init -2
this will initialize a new yarn v2 project folder with .yarnrc.yml, package.json, and the .yarn folder, also initializes an empty .git folder and adds a proper .gitignore. check by yarn --version - should echo v2.x.x
Usage Error: The nearest package directory (/<path_to_folder>/<project_name>) doesn't seem to be part of the project declared in /<path_to_folder>.
Solution:
Search for yarn.lock and package.json files inside /<path_to_folder> and delete them!
you have to remove yarn.lock and package.json file in your root directory ,some times there may be .yarnrc yarnyml files in you root directory you have to remove them also.

Yarn can't find private Github npm registry

I signed up for the Github private npm registry beta and followed their instruction: https://github.com/features/package-registry
Works great with npm but I'd prefer using yarn. And while npm has no issues finding the registered package, yarn can't find it at all.
yarn add #omniphx/adminite-adminite-ui-components outputs:
yarn add v1.19.0
info No lockfile found.
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍 Resolving packages...
error Couldn't find package "#omniphx/adminite-ui-components" on the "npm" registry.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
After reading up on private repos with yarn, I thought the trick was due to yarn having a slightly different rc format. Unfortunately, that didn't work either and yarn is still unable to find the private registry.
.npmrc
registry=https://registry.npmjs.org
#omniphx:registry=https://npm.pkg.github.com/omniphx
.yarnrc
registry "https://registry.npmjs.org"
"#omniphx:registry" "https://npm.pkg.github.com/omniphx"
Also confirmed that my github token is set too with yarn config list:
yarn config v1.19.0
info yarn config
{
'version-tag-prefix': 'v',
'version-git-tag': true,
'version-commit-hooks': true,
'version-git-sign': false,
'version-git-message': 'v%s',
'init-version': '1.0.0',
'init-license': 'MIT',
'save-prefix': '^',
'bin-links': true,
'ignore-scripts': false,
'ignore-optional': false,
registry: 'https://registry.npmjs.org',
'strict-ssl': true,
'user-agent': 'yarn/1.19.0 npm/? node/v12.11.1 darwin x64',
email: 'mattjmitchener#gmail.com',
lastUpdateCheck: 1570679687836,
username: 'omniphx',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx'
}
info npm config
{
'//npm.pkg.github.com/:_authToken': 'fake12345',
registry: 'https://registry.npmjs.org',
'#omniphx:registry': 'https://npm.pkg.github.com/omniphx',
python: '/usr/bin/python'
}
Any idea?
Resolved
Changed "#myorg:registry" "https://npm.pkg.github.com/myorg"
To "#myorg:registry" "https://npm.pkg.github.com"
I've just run into a similar situation. It seemed that yarn was only looking in the main Yarn package registry for my organization's private package. I had copied the examples from GitHub's Packages documentation for constructing your .npmrc file directly to the .yarnrc file in the project that will be consuming the app, not knowing that the formats were different (I've never had to deal with .yarnrc files before).
However, after updating the .yarnrc file with the correct format that you've mentioned above (which I also found in googling around), yarn successfully found the private package and installed it correctly.
As a heads up, my yarn version: 1.17.3
Steps I Took
Start new terminal session
cd to the project
nvm use (if you have a specific node version to use)
Add the correctly-formatted .yarnrc file to the project. See below for what it looks like.
Manually add the package and version range to the package.json for my private package
Run npm login --registry=https://npm.pkg.github.com --scope=#MyOrg
See the note below on scope / org gotcha's
Run yarn
That worked for me.
.yarnrc
"#myorg:registry" "https://npm.pkg.github.com"
Note: See below for a note on the org / scope name gotcha's
Other Notes
I know that it appears that you don't have any issues with this, given your GH username / scope above, but for anyone else that comes here, the documentation on GH is a little sparse with regards to mapping your username / org name to a scope in the package name. Just remember these little gotcha's here:
The name of your package must always be scoped to your org (or username)
E.g., name: #johndturn/my-package
If your organization has capital letters in it, like MyOrg, just replace them in the name of the package in your package.json and your .yarnrc with lowercase
E.g., name: #myorg/my-package
Note: When authenticating with npm login, I still have kept the uppercase letters in the --scope= argument.
The name of your package doesn't have to be the same name of the repo.
E.g., for a repo called MyOrg/random-prefix.js-lib, you can have name: #myorg/js-lib in your package.json file for the project itself. Then, installing it in other projects will look something like #myorg/js-lib: 1.0.0.
The problem I had is slightly different.
After tried what John suggested I still can't add private registry packages with yarn (but perfectly fine with npm)
Then I realise two things:
For GitHub packages, npm is fine with either
registry=https://npm.pkg.github.com/my-org
or
#my-org:registry=https://npm.pkg.github.com
but yarn only allow the latter syntax.
Docs from Github website only show the first syntax which could cause problems for yarn users.
Another thing is that if you npm login to the private registry but use a .yarnrc file in your project, yarn can't really mix your npm credentials with it. Although it seems behave differently on different environment.
But it would seems to be a best practice to stick with either yarn login + .yarnrc, or npm login + .npmrc (you can still use yarn to manage your packages in both cases)
In Yarn v2+ the setup has changed quite a bit. ".yarnrc" is ignored and only ".yarnrc.yml" is used.
To setup a private registry with a scope and token from env, add something along these lines to the ".yarnrc.yml" file (fontawesome example):
npmScopes:
fortawesome:
npmRegistryServer: "https://npm.fontawesome.com"
npmAuthToken: ${FONTAWESOME_TOKEN}
Documentation: https://yarnpkg.com/configuration/yarnrc#npmScopes
I'm not an expert with npm/yarn so I might be misunderstanding what is happening here, but I don't think package proxying from the npm registry works with yarn yet. Could that be related? When package proxying was released for npm I remember reading comments on Twitter from people that tried it with yarn and it didn't work.
Found the Twitter thread here:
https://twitter.com/github/status/1171832034580451328
It doesn't work with Yarn. As soon as I change the registry url -> Couldn't find package.

How to build Conda env on Mac using Windows yml file?

I'm creating Conda create environment from yml I generated on Windows' Miniconda install. I need to create same environment on OS X. Following the advise found here on SO I used the --no-builds option.
Also, the names of some packages under section ResolvePackageNotFound are clearly (many if not all) specific to Windows:
- m2w64-gmp=6.1.0
- m2w64-gcc-libs-core=5.3.0
- m2w64-gcc-libs=5.3.0
- vc=14.1
- vs2015_runtime=15.5.2
- msys2-conda-epoch=20160418
- menuinst=1.4.14
- icc_rt=2019.0.0
- m2w64-libwinpthread-git=5.0.0.4634.697f757
- pywinpty=0.5.5
- wincertstore=0.2
- m2w64-gcc-libgfortran=5.3.0
- win_inet_pton=1.1.0
- winpty=0.4.3
I removed all of these from the yml file. Even then it's stalled at the following screen:
(base) MacBook-Air:Anaconda.d xtian$ conda env create -f 32b-qb-2019-10-05.yml
Collecting package metadata (repodata.json): done
Solving environment: \
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abor|
Examining openssl: 10%|█████████▍ | 29/279 [00:00<00:00, 3729.87it- ]
Comparing specs that have this dependency: 16%|██████████▉ | 16/101 [05:53<31:19, 22.11s/it]
Finding shortest conflict path for openssl[version='>=1.0.2p,<1.0.3a']: 38%|███████████████▊ | 6/16 [02:39<06:23, 38.32s/it]
This process is progressing at an astonishingly slow pace, and hasn't got past openssl ... 29/279. Should I wait and trust Conda can figure this all out?
Or,
Do I need another strategy--
I'm wondering if I can't remove the offending packages, each in turn, and create a series of yml files to install in order using, $ conda env update --prefix ./env --file environment.yml --prune, because whatever finally works here I know I'm going to need to use it on another machine so I can share the project env with a colleague.
Any other suggestions?
Short answer: Try deleting the packages that your system is getting stuck on from the .yml file. i.e., remove "openssl" from .yml file.
I have been running into the same issue trying to install a .yml file created in a Windows system to a Mac system. I basically followed the same procedure you did:
-Created yml file using the --no-builds option.
-Attempted to create environment on Mac system and had several windows specific packages left under ResolvePackageNotFound section (listed below)
m2w64-libwinpthread-git=5.0.0.4634.697f757
pyreadline=2.1
pywinpty=0.5.5
m2w64-gcc-libgfortran=5.3.0
vc=14
m2w64-gcc-libs-core=5.3.0
m2w64-gmp=6.1.0
wincertstore=0.2
icc_rt=2019.0.0
m2w64-gcc-libs=5.3.0
vs2015_runtime=14.15.26706
winpty=0.4.3
msys2-conda-epoch=20160418
-Deleted those from the yml file
-Attempted to create environment from updated yml file and received the following conflicts:
- Found conflicts! Looking for incompatible packages.
My system also got stuck trying to solve the "openssl" conflict along with a "_tflow_select". I ended up deleting those and was able to create my environment and run the code without too much trouble.

gitignore not ignoring opencv2.framework

I am trying to make git ignore the opencv2.framework I have imported into my project. However, even though I am adding opencv2.framework into my .gitignore, every time I run git status on my terminal, all the opencv2.framework files are showing up as new files. Could anybody help? Thanks! This is what my .gitignore file looks like: (I wrote opencv2.framework under ##Various Settings)
# Xcode
#
# gitignore contributors: remember to update Global/Xcode.gitignore, Objective-C.gitignore & Swift.gitignore
## Build generated
build/
DerivedData/
## Various settings
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata/
opencv2.framework/
## Other
*.moved-aside
*.xccheckout
*.xcscmblueprint
## Obj-C/Swift specific
*.hmap
*.ipa
*.dSYM.zip
*.dSYM
## Playgrounds
timeline.xctimeline
playground.xcworkspace
# Swift Package Manager
#
# Add this line if you want to avoid checking in source code from Swift Package Manager dependencies.
# Packages/
# Package.pins
.build/
# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
#
# Pods/
# Carthage
#
# Add this line if you want to avoid checking in source code from Carthage dependencies.
# Carthage/Checkouts
Carthage/Build
# fastlane
#
# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the
# screenshots whenever they are needed.
# For more information about the recommended setup visit:
# https://docs.fastlane.tools/best-practices/source-control/#source-control
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots
fastlane/test_output
Just in case, see if git status changes after:
cd /path/to/my/repo
git rm -r --cached opencv2.framework/
If it does (and you don't see anymore opencv2.framework/ files), commit your current state.
You need to execute the git rm -r --cached:
in the parent repo of the folder to remove (parent of opencv2.framework/).
Do add and commit (and eventually push), in order to record that deletion from the git repo (but not from the disk, thanks to the --cached option);
in order to delete those tracked files, as a .gitignore rule only applies to untracked files.