Rework publishing to work with all popular package managers

fixes https://github.com/atlassian/changesets/issues/598
fixes https://github.com/atlassian/changesets/issues/432
at the moment this is being opened as a draft, to gather initial feedback
The goal of this PR is to delegate as much as possible to yarn berry / pnpm so they can do their magic with rewriting package manifests and stuff
TODO:

[ ] implement improved authentication setup for yarn berry in the https://github.com/changesets/action since it doesn't rely on .npmrc

cc @schickling @zkochan (might be interesting to you)

@belgattitude thank you very much for testing this ❤ I will make necessary changes here soon, I would only want to land this first https://github.com/atlassian/changesets/pull/676 so I could rebase this one on top of it.

@belgattitude I've rebased this and applied your suggestions. I've also created a PR to add snapshot releases (here). This can only be merged in when we confirm that it has been done in a secure way, so I don't want to rush it. If you could retest this PR "manually" (like you have done before) - I would highly appreciate it.

Hey @Andarist thanks a lot. Here it is

yarn changeset publish
sebastien@seb-thinkpad-x1:~/github/cache-interop$ yarn changeset publish
🦋  warn ===============================IMPORTANT!===============================
🦋  warn You are in prerelease mode so packages will be published to the canary
🦋  warn         dist tag except for packages that have not had normal releases which will be published to latest
🦋  warn ----------------------------------------------------------------------
🦋  info npm info @soluble/cache-interop
🦋  info npm info @soluble/cache-ioredis
🦋  info npm info @soluble/cache-redis
🦋  info npm info @soluble/dsn-parser
🦋  info @soluble/cache-interop is being published because our local version (0.8.2-canary.0) has not been published on npm
🦋  info @soluble/cache-ioredis is being published because our local version (0.8.4-canary.0) has not been published on npm
🦋  info @soluble/cache-redis is being published because our local version (0.8.4-canary.0) has not been published on npm
🦋  info @soluble/dsn-parser is being published because our local version (1.3.3-canary.0) has not been published on npm
🦋  info Publishing "@soluble/cache-interop" at "0.8.2-canary.0"
🦋  info Publishing "@soluble/cache-ioredis" at "0.8.4-canary.0"
🦋  info Publishing "@soluble/cache-redis" at "0.8.4-canary.0"
🦋  info Publishing "@soluble/dsn-parser" at "1.3.3-canary.0"
🦋  info will publish with 'yarn npm publish --access public --tag canary'
🦋  info will publish with 'yarn npm publish --access public --tag canary'
🦋  info will publish with 'yarn npm publish --access public --tag canary'
🦋  info will publish with 'yarn npm publish --access public --tag canary'
🦋  error an error occurred while publishing @soluble/dsn-parser:
🦋  error ➤ YN0033: No authentication configured for request
🦋  error an error occurred while publishing @soluble/cache-ioredis:
🦋  error ➤ YN0033: No authentication configured for request
🦋  error an error occurred while publishing @soluble/cache-redis:
🦋  error ➤ YN0033: No authentication configured for request
🦋  error an error occurred while publishing @soluble/cache-interop:
🦋  error ➤ YN0033: No authentication configured for request
🦋  error packages failed to publish:
🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>

The command is not complaining anymore with yarn 3.2.0-rc.6.

🦋  info will publish with 'yarn npm publish --access public --tag canary'

PS: I've added the log here: https://github.com/atlassian/changesets/pull/682/files just to be sure.
That said it's not a full publish, I'll need --otp for that and can only publish my repo from a gh action for now.
So all look fine. My concerns are related to

Logging: As it look probable we run into bugs, I would add some logging about the command used.
Prevent regressions: I feel we should be still have some kind of unit tests for the command (and pm versions). To ensure future change does not break things.

Of course all is up to you, I come from different ecosystem so my reflexes often lack perspective and love to learn and share in general.
Let me know I still have few free days, and I'll gladly help.

Logging: As it look probable we run into bugs, I would add some logging about the command used.

That's probably a good call - anything that you would like to see logged beside the information added in your PR here?

Prevent regressions: I feel we should still have some kind of unit tests for the command (and pm versions). To ensure future changes does not break things.

I agree that we need some tests here - I'm just on the fence when it comes to unit tests here. The logic itself is pretty straightforward - the only problem is that I'm not always sure what exact combination of options has to be passed in a specific situation. And when it comes to that I think that comments can be more valuable than unit tests.
I just kinda feel that I would be that more confident about this logic if I would have those unit tests. I'm not a testing expert though and probably many people would say that this would be worthwhile - I'm just not feeling that. Maybe @mitchellhamilton would have some additional opinion about this.

The command is not complaining anymore with yarn 3.2.0-rc.6.

Just to make sure that we are on the same page - everything looks OK now from your end, it's just that publish fails because OTP is required and you are not using the automation token because you are running the publish script locally and not on the CI. Right?

testing

tbh, what I'd really like is tests that run with all the different package managers against a local registry (probably https://verdaccio.org) with a way to run the tests against actual registries.

Let's move the tests-related discussion to the dedicated thread. I don't think this is sort of out of the scope of this PR and should be addressed separately.

anything that you would like to see logged beside the information added in your PR here?

New to the project so I don't know but I would follow the concerns from https://github.com/atlassian/changesets/pull/674#pullrequestreview-811980332 @mitchellhamilton

Just to make sure that we are on the same page - everything looks OK now from your end, it's just that publish fails because OTP is required

Yep. Don't want to mess too much my repo :smile:. A canary of changeset can help for me to test it out fully, but as the "yarn command" is okay, I feel I can be confident enough the tool will do it's job.

About tests

Just want to express something about unit.  I'm certainly not trying to create a debate, just sharing and if it's not useful, please forget.

Don't test what you don't own.
I like the idea of e2e, but in this specific case I would be confident that:

given the package manager cli receive the correct params it will do the job or it's a bug on their side. They have an e2e suite that runs on many os... spawn (which I don't know about) has it's own tests too, I guess. So for me what is to test is the command we run, less the fact that npm, pnpm, yarn 1.2.3 will actually publish what what we are feeding to it. Command line is somehow a contract. Same idea when I test a server, do I need to test if my express server works or just my handler/use-case (business...) .... There's not big difference when you write the tests, but running them is much easier when you don't need to start the actual express server (time, flacky...).

What kind of unit tests
For example we could list the commands that are expected by each tool (from their doc). To illustrate (I haven't checked just taken from what I read in this P/R)

Given
Expected

Yarn 1  --otp
npm publish --access public --tag main --otp xxx --json

Yarn 1
npm publish --access public --tag main --json

Yarn 2
yarn npm publish --access public --tag main

Yarn 2  --otp
should throw 'Unsupported --otp, upgrade to yarn 3.2+'

Yarn 3.2 --otp
yarn npm publish --access public --tag main --otp xxx

Pnpm 6
yarn npm publish --access public --tag main --json --no-git-checks

Npm 6  --otp
npm publish --access public --tag main --otp xxx --json

Npm 8  --otp
npm publish --access public --tag main --otp xxx --json

That could be written in many ways... In this scenario looks a fit for kind of acceptance / BDD / cucumber style. either given/when/expect like here or even with a simple it.each and an array of scenarios.
That should suffice to prevent regressions, as you said the code is trivial but how much variations will come in the future. Personally as a contributor (If I become, I'll become :smile: ) I would be more confident to make changes.

If you like I could add an example test file in a separate P/R... The only thing is that I don't really know node, so a reviewer/guide will be needed :smile:
Hey thanks again

@Andarist a little addition. I'm not sure you're aware of it. When I faced the issue with yarn/pnpm workspace: protocol, I just did a quick hack for my own use case. Rather than change npm for publication, I intercepted the pack step (yarn pack, pnpm pack) to generate the archive. see here https://github.com/atlassian/changesets/pull/585#issuecomment-940756397.
I'm thinking of it now, I guess it's a bit late to tell and I don't want to add confusion here. So feel free to ignore, but it might help to harmonize and have one tool to test for publishing.

@mitchellhamilton  any updates?

@ragingwind I still have some minor things to adjust here and to figure out the authentication story in changesets/action. I didn't have much time to spend on this lately - but I will be working on landing this PR as soon as I can.

@Andarist Thank you. It would be great I could use it with prerelease. We use<EMAIL_ADDRESS>now

@Andarist definitely looking forward to this PR, we are attempting to upgrade our monorepo from yarn v1 to yarn v3 and would like to also retain our conventional-commits/semantic releases that lerna used to give but is no longer compatible with yarn berry

@ragingwind I would say that at the moment using this packed version from CodeSandbox CI is the easiest:
@changesets/cli<EMAIL_ADDRESS>
Since you are using Yarn 3 you'd have to use this Yarn plugin to resolve requested dependencies correctly.
You could also try installing this version from npm:
<EMAIL_ADDRESS>
but it's a little behind the one available on CodeSandbox CI - and any future prereleases like that will only be available through CodeSandbox CI so that's what I recommend now.
Note that if you are also using changesets/actions then you should authenticate correctly before calling our action, otherwise Yarn won't be able to authenticate publish requests. I'm a little bit worried that npm info calls might fail either way - but if you could confirm that then I would have an actionable item to fix as part of this PR.

and would like to also retain our conventional-commits/semantic releases that lerna used to give

@ilyaGurevich note that how Changesets work is slightly different from that - the generated changelog updates etc are not based on commit messages but on the committed changeset .md files

Also notice that changeset is reading registry settings from .npmrc instead of .yarnrc.yml even the repo is using yarn instead of npm.

@Andarist do you need some additional help to finish it?

hw is this pr going and when will i be able to use this? atm moment i really need this because my publishing automation for my project is broken due to yarn not being supported.

Just checking on this PR, keen to see it finished. @Andarist if you need any help (or sponsorship) to see it through, I'd be happy to help, it's an awesome tool otherwise. 🦋

are there any updates on this, we really miss the great capabilities of yarn changeset publish

how about this issue progress? really need this feature without any hack.

@Andarist using<EMAIL_ADDRESS>publish failed.
➤ YN0000: Done in 7s 668ms
🦋  info npm info @armit/cli
🦋  info npm info @armit/common
🦋  info npm info @armit/eslint-config-bases
🦋  info @armit/cli is being published because our local version (0.0.5) has not been published on npm
🦋  info @armit/common is being published because our local version (0.0.5) has not been published on npm
🦋  info @armit/eslint-config-bases is being published because our local version (0.0.4) has not been published on npm
🦋  info Publishing "@armit/cli" at "0.0.5"
🦋  info Publishing "@armit/common" at "0.0.5"
🦋  info Publishing "@armit/eslint-config-bases" at "0.0.4"
🦋  error an error occurred while publishing @armit/eslint-config-bases:
🦋  error ➤ YN0000: CHANGELOG.md
🦋  error ➤ YN0000: README.md
🦋  error ➤ YN0000: package.json
🦋  error ➤ YN0000: src/bases/index.js
🦋  error ➤ YN0000: src/bases/jest.js
🦋  error ➤ YN0000: src/bases/playwright.js
🦋  error ➤ YN0000: src/bases/prettier.js
🦋  error ➤ YN0000: src/bases/react.js
🦋  error ➤ YN0000: src/bases/regexp.js
🦋  error ➤ YN0000: src/bases/rtl.js
🦋  error ➤ YN0000: src/bases/sonar.js
🦋  error ➤ YN0000: src/bases/storybook.js
🦋  error ➤ YN0000: src/bases/tailwind.js
🦋  error ➤ YN0000: src/bases/typescript.js
🦋  error ➤ YN0000: src/bases/vitest.js
🦋  error ➤ YN0000: src/helpers/getDefaultIgnorePatterns.js
🦋  error ➤ YN0000: src/helpers/getPrettierConfig.js
🦋  error ➤ YN0000: src/helpers/index.js
🦋  error ➤ YN0000: src/index.js
🦋  error ➤ YN0000: src/patch/modern-module-resolution.js
🦋  error ➤ YN0000: src/prettier.base.config.js
🦋  error ➤ YN0033: No authentication configured for request
🦋  error an error occurred while publishing @armit/cli:
🦋  error ➤ YN0000: CHANGELOG.md
🦋  error ➤ YN0000: LICENSE
🦋  error ➤ YN0000: README.md
🦋  error ➤ YN0000: bin/armit.mjs
🦋  error ➤ YN0000: dist/index.d.ts
🦋  error ➤ YN0000: dist/index.js
🦋  error ➤ YN0000: dist/index.js.map
🦋  error ➤ YN0000: index.js
🦋  error ➤ YN0000: package.json
🦋  error ➤ YN0033: No authentication configured for request
🦋  error an error occurred while publishing @armit/common:
🦋  error ➤ YN0000: CHANGELOG.md
🦋  error ➤ YN0000: LICENSE
🦋  error ➤ YN0000: README.md
🦋  error ➤ YN0000: dist/index.d.ts
🦋  error ➤ YN0000: dist/index.js
🦋  error ➤ YN0000: dist/index.js.map
🦋  error ➤ YN0000: index.js
🦋  error ➤ YN0000: package.json
🦋  error ➤ YN0033: No authentication configured for request
🦋  error packages failed to publish:
🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>🦋<EMAIL_ADDRESS>Error: The process '/usr/local/bin/yarn' failed with exit code 1
at m._setResult (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:7258)
Error: The process '/usr/local/bin/yarn' failed with exit code 1
at m.CheckComplete (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:6686)
at ChildProcess. (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:5723)
at ChildProcess.emit (events.js:314:20)
at maybeClose (internal/child_process.js:1022:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)

@Andarist could you please rebase with the main branch? I need the latest main branch changes in the csb releases.

I've been trying out this PR with @qnighy's patch and with yarn 4.0.0-rc.45
I get the following error message when running yarn changeset publish:
🦋  error error while checking if token is required npm ERR! code E401
🦋  error npm ERR! 401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user
🦋  error {
🦋  error   "error": {
🦋  error     "code": "E401",
🦋  error     "summary": "401 Unauthorized - GET https://registry.npmjs.org/-/npm/v1/user",
🦋  error     "detail": ""
🦋  error   }
🦋  error }
🦋  error
🦋  error npm ERR! A complete log of this run can be found in:
🦋  error npm ERR!     /Users/jun/.npm/_logs/2023-06-09T10_56_34_917Z-debug-0.log

I traced this to the fact that getTokenIsRequired() is still in the hotpath, but that would require npm profile get --json to work, whereas it's not configured (since yarn uses .yarnrc.yml for registry configuration.
If I simply short circuit this function and return false; then it works. A temporary fix of course, but I hope this would help and maybe give back a tiny bit of momentum to get this over the line. Happy to test new patches!

Just bumped into the fact that for changesets to check if the package is published in a registry, it uses getPackageInfo which is still using npm info instead of yarn npm info. In the case where registry access is configured only through a .yarnrc.yml file this will fail with a 404 (since it doesn't use the proper registry for that @scope) and will try to republish the package which is already in the registry, and fail if the package was already published (since the yarn npm publish part works correctly).
🦋  warn Received 404 for npm info "@scope/package"
🦋  info @scope/package is being published because our local version (0.0.0) has not been published on npm
🦋  info Publishing "@scope/package" at "0.0.0"
🦋  error an error occurred while publishing @scope/package:
🦋  error ➤ YN0000: output/Main/index.js
🦋  error ➤ YN0000: package.json
🦋  error ➤ YN0035: The remote server failed to provide the requested resource
🦋  error ➤ YN0035:   Response Code: [40](https://github.com/org/repo/actions/runs/.../jobs/...#step:12:41)3 (Forbidden)
🦋  error ➤ YN0035:   Request Method: PUT
🦋  error ➤ YN0035:   Request URL: https://gitlab.com/api/v4/projects/.../packages/npm/@scope%2fpackage
🦋  error packages failed to publish:
🦋<EMAIL_ADDRESS>
A similar logic than internalPublish but for yarn npm info works https://github.com/changesets/changesets/blob/760821164b4f144e7aca2bd4d410dce8c5ce641d/packages/cli/src/commands/publish/npm-utils.ts#L189-L197
Here's an updated version of the above patch:

<EMAIL_ADDRESS>diff --git a/dist/cli.cjs.dev.js b/dist/cli.cjs.dev.js
index b1582198d3d2631569ff59f27170354a932d3ad0..2826a10919ca861e82efa105b6604fa52eda9847 100644
--- a/dist/cli.cjs.dev.js
+++ b/dist/cli.cjs.dev.js
@@ -1,5 +1,4 @@
 'use strict';
-
 var meow = require('meow');
 var errors = require('@changesets/errors');
 var logger = require('@changesets/logger');
@@ -705,31 +704,33 @@ function getCorrectRegistry(packageJson) {
   return !registry || registry === "https://registry.yarnpkg.com" ? "https://registry.npmjs.org" : registry;
 }
+const getPublishToolVersion = async (name, cwd) => (await spawn__default['default'](name, ["--version"], {

cwd
+})).stdout.toString().trim();

async function getPublishTool(cwd) {

const pm = await preferredPM__default'default';
if (!pm || pm.name !== "pnpm") return {
name: "npm"
};

var _await$preferredPM;

try {
let result = await spawn__default['default']("pnpm", ["--version"], {

 cwd

});
let version = result.stdout.toString().trim();
let parsed = semver__default['default'].parse(version);
return {

 name: "pnpm",

 shouldAddNoGitChecks: (parsed === null || parsed === void 0 ? void 0 : parsed.major) === undefined ? false : parsed.major >= 5

};
} catch (e) {

const name = ((_await$preferredPM = await preferredPM__default'default') === null || _await$preferredPM === void 0 ? void 0 : _await$preferredPM.name) || "npm";
const version = await getPublishToolVersion(name, cwd);

if (name === "yarn" && semver__default['default'].lt(version, "2.0.0")) {
// Yarn Classic doesn't do anything special when publishing, let's stick to the npm client in such a case
return {

 name: "pnpm",

 shouldAddNoGitChecks: false

 name: "npm",

 version: await getPublishToolVersion("npm", cwd)

};
}

return {
name,
version
};
}

async function getTokenIsRequired() {

let publishTool = await getPublishTool(process.cwd());
if (publishTool.name === "yarn") return false;
// Due to a super annoying issue in yarn, we have to manually override this env variable
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633
const envOverride = {
@@ -754,6 +755,7 @@ async function getTokenIsRequired() {
}
function getPackageInfo(packageJson) {
return npmRequestLimit(async () => {
let publishTool = await getPublishTool(process.cwd());
logger.info(npm info ${packageJson.name}); // Due to a couple of issues with yarnpkg, we also want to override the npm registry when doing
// npm info.
// Issues: We sometimes get back cached responses, i.e old data about packages which causes
@@ -761,7 +763,9 @@ function getPackageInfo(packageJson) {
// as they will always give a 404, which will tell publish to always try to publish.
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633

let result = await spawn__default['default']("npm", ["info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json"]); // Github package registry returns empty string when calling npm info

let result = publishTool.name === "yarn" ? await spawn__default['default']("yarn", ["npm", "info", packageJson.name, "--json"], {

 env: Object.assign({}, process.env)

}) : await spawn__default['default']("npm", ["info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json"]); // Github package registry returns empty string when calling npm info
// for a non-existent package instead of a E404
if (result.stdout.toString() === "") {
@@ -816,20 +820,32 @@ let getOtpCode = async twoFactorState => {
}

return askForOtpCode(twoFactorState);
+};
+
+const isOtpError = error => {

// The first case is no 2fa provided, the second is when the 2fa is wrong (timeout or wrong words)

return error.code === "EOTP" || error.code === "E401" && error.detail.includes("--otp=");
}; // we have this so that we can do try a publish again after a publish without
// the call being wrapped in the npm request limit and causing the publishes to potentially never run

async function internalPublish(pkgName, opts, twoFactorState) {
let publishTool = await getPublishTool(opts.cwd);

let publishFlags = opts.access ? ["--access", opts.access] : [];

let shouldHandleOtp = !isCI__default['default'] && (publishTool.name === "yarn" ? semver__default['default'].gte(publishTool.version, "3.2.0-rc.8") : true);
let publishFlags = publishTool.name !== "yarn" ? ["--json"] : [];

if (opts.access) {
publishFlags.push("--access", opts.access);
}
publishFlags.push("--tag", opts.tag);

if ((await twoFactorState.isRequired) && !isCI__default['default']) {

if (shouldHandleOtp && (await twoFactorState.isRequired)) {
let otpCode = await getOtpCode(twoFactorState);
publishFlags.push("--otp", otpCode);
}

if (publishTool.name === "pnpm" && publishTool.shouldAddNoGitChecks) {

if (publishTool.name === "pnpm" && semver__default['default'].gte(publishTool.version, "5.0.0")) {
publishFlags.push("--no-git-checks");
} // Due to a super annoying issue in yarn, we have to manually override this env variable
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633
@@ -842,21 +858,35 @@ async function internalPublish(pkgName, opts, twoFactorState) {
code,
stdout,
stderr

} = await spawn__default['default'](publishTool.name, ["publish", opts.cwd, "--json", ...publishFlags], {

} = publishTool.name === "yarn" ? await spawn__default['default']("yarn", ["npm", "publish", ...publishFlags], {

cwd: opts.cwd,

env: Object.assign({}, process.env, envOverride)

}) : await spawn__default['default'](publishTool.name, ["publish", opts.cwd, ...publishFlags], {
env: Object.assign({}, process.env, envOverride)
});
if (code !== 0) {

// NPM's --json output is included alongside the prepublish and postpublish output in terminal

// yarn berry doesn't support --json and we don't attempt to parse its output to a machine-readable format

if (publishTool.name === "yarn") {

 const output = stdout.toString().trim().split("\n") // this filters out "unnamed" logs: https://yarnpkg.com/advanced/error-codes/#yn0000---unnamed

 // this includes a list of packed files and the "summary output" like: "Failed with errors in 0s 75ms"

 // those are not that interesting so we reduce the noise by dropping them

 .filter(line => !/YN0000:/.test(line)).join("\n");

 logger.error(`an error occurred while publishing ${pkgName}:`, `\n${output}`);

 return {

   published: false

 };

} // NPM's --json output is included alongside the prepublish and postpublish output in terminal
// We want to handle this as best we can but it has some struggles:
// - output of those lifecycle scripts can contain JSON
// - npm7 has switched to printing --json errors to stderr (https://github.com/npm/cli/commit/1dbf0f9bb26ba70f4c6d0a807701d7652c31d7d4)
// Note that the --json output is always printed at the end so this should work

let json = getLastJsonObjectFromString(stderr.toString()) || getLastJsonObjectFromString(stdout.toString());
if (json !== null && json !== void 0 && json.error) {

 // The first case is no 2fa provided, the second is when the 2fa is wrong (timeout or wrong words)

 if ((json.error.code === "EOTP" || json.error.code === "E401" && json.error.detail.includes("--otp=<code>")) && !isCI__default['default']) {

 if (shouldHandleOtp && isOtpError(json.error)) {
   if (twoFactorState.token !== null) {
     // the current otp code must be invalid since it errored
     twoFactorState.token = null;

diff --git a/dist/cli.cjs.prod.js b/dist/cli.cjs.prod.js
index 5b1b7dd6439be4f0b721a17e683b1435c254f5b8..803762c16b9c7f484948171e42e1d8b4d95cbc7c 100644
--- a/dist/cli.cjs.prod.js
+++ b/dist/cli.cjs.prod.js
@@ -1,5 +1,5 @@
"use strict";
+console.log()
var meow = require("meow"), errors = require("@changesets/errors"), logger = require("@changesets/logger"), util = require("util"), fs = require("fs-extra"), path = require("path"), getPackages = require("@manypkg/get-packages"), getDependentsGraph = require("@changesets/get-dependents-graph"), config = require("@changesets/config"), chalk = require("chalk"), child_process = require("child_process"), termSize = require("term-size"), enquirer = require("enquirer"), externalEditor = require("external-editor"), ansiColors = require("ansi-colors"), git = require("@changesets/git"), writeChangeset = require("@changesets/write"), resolveFrom = require("resolve-from"), semver = require("semver"), outdent = require("outdent"), applyReleasePlan = require("@changesets/apply-release-plan"), readChangesets = require("@changesets/read"), assembleReleasePlan = require("@changesets/assemble-release-plan"), pre$1 = require("@changesets/pre"), pLimit = require("p-limit"), preferredPM = require("preferred-pm"), spawn = require("spawndamnit"), isCI = require("is-ci"), table = require("tty-table"), getReleasePlan = require("@changesets/get-release-plan");
function _interopDefault(e) {
@@ -396,28 +396,25 @@ function getCorrectRegistry(packageJson) {
return registry && "https://registry.yarnpkg.com" !== registry ? registry : "https://registry.npmjs.org";
}
+const getPublishToolVersion = async (name, cwd) => (await spawn__default.default(name, [ "--version" ], {

cwd: cwd
+})).stdout.toString().trim();

async function getPublishTool(cwd) {

const pm = await preferredPM__default.default(cwd);
if (!pm || "pnpm" !== pm.name) return {
name: "npm"

var _await$preferredPM;
const name = (null === (_await$preferredPM = await preferredPM__default.default(cwd)) || void 0 === _await$preferredPM ? void 0 : _await$preferredPM.name) || "npm", version = await getPublishToolVersion(name, cwd);
return "yarn" === name && semver__default.default.lt(version, "2.0.0") ? {
name: "npm",
version: await getPublishToolVersion("npm", cwd)
} : {
name: name,
version: version
};

try {
let version = (await spawn__default.default("pnpm", [ "--version" ], {

 cwd: cwd

})).stdout.toString().trim(), parsed = semver__default.default.parse(version);
return {

 name: "pnpm",

 shouldAddNoGitChecks: void 0 !== (null == parsed ? void 0 : parsed.major) && parsed.major >= 5

};
} catch (e) {
return {

 name: "pnpm",

 shouldAddNoGitChecks: !1

};
}
}

async function getTokenIsRequired() {

let publishTool = await getPublishTool(process.cwd());
if (publishTool.name === "yarn") return false;
const envOverride = {
npm_config_registry: getCorrectRegistry()
};
@@ -432,8 +429,11 @@ async function getTokenIsRequired() {

function getPackageInfo(packageJson) {
return npmRequestLimit((async () => {

let publishTool = await getPublishTool(process.cwd());
logger.info("npm info " + packageJson.name);

let result = await spawn__default.default("npm", [ "info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json" ]);

let result = "yarn" === publishTool.name ? await spawn__default.default("yarn", [ "npm", "info", packageJson.name, "--json" ], {
env: Object.assign({}, process.env)
}) : await spawn__default.default("npm", [ "info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json" ]);
return "" === result.stdout.toString() ? {
error: {
code: "E404"
@@ -466,23 +466,36 @@ let otpAskLimit = pLimit__default.default(1), askForOtpCode = twoFactorState =>
return twoFactorState.token = val, val;
})), getOtpCode = async twoFactorState => null !== twoFactorState.token ? twoFactorState.token : askForOtpCode(twoFactorState);

+const isOtpError = error => "EOTP" === error.code || "E401" === error.code && error.detail.includes("--otp=");
+
async function internalPublish(pkgName, opts, twoFactorState) {

let publishTool = await getPublishTool(opts.cwd), publishFlags = opts.access ? [ "--access", opts.access ] : [];
if (publishFlags.push("--tag", opts.tag), await twoFactorState.isRequired && !isCI__default.default) {

let publishTool = await getPublishTool(opts.cwd), shouldHandleOtp = !isCI__default.default && ("yarn" !== publishTool.name || semver__default.default.gte(publishTool.version, "3.2.0-rc.8")), publishFlags = "yarn" !== publishTool.name ? [ "--json" ] : [];
if (opts.access && publishFlags.push("--access", opts.access), publishFlags.push("--tag", opts.tag),
shouldHandleOtp && await twoFactorState.isRequired) {
let otpCode = await getOtpCode(twoFactorState);
publishFlags.push("--otp", otpCode);
}

"pnpm" === publishTool.name && publishTool.shouldAddNoGitChecks && publishFlags.push("--no-git-checks");

"pnpm" === publishTool.name && semver__default.default.gte(publishTool.version, "5.0.0") && publishFlags.push("--no-git-checks");
const envOverride = {
npm_config_registry: getCorrectRegistry()
};

let {code: code, stdout: stdout, stderr: stderr} = await spawn__default.default(publishTool.name, [ "publish", opts.cwd, "--json", ...publishFlags ], {

let {code: code, stdout: stdout, stderr: stderr} = "yarn" === publishTool.name ? await spawn__default.default("yarn", [ "npm", "publish", ...publishFlags ], {
cwd: opts.cwd,
env: Object.assign({}, process.env, envOverride)
}) : await spawn__default.default(publishTool.name, [ "publish", opts.cwd, ...publishFlags ], {
env: Object.assign({}, process.env, envOverride)
});
if (0 !== code) {
if ("yarn" === publishTool.name) {

 const output = stdout.toString().trim().split("\n").filter((line => !/YN0000:/.test(line))).join("\n");

 return logger.error(`an error occurred while publishing ${pkgName}:`, "\n" + output),

 {

   published: !1

 };

}
let json = getLastJsonObjectFromString(stderr.toString()) || getLastJsonObjectFromString(stdout.toString());
if (null != json && json.error) {

 if (("EOTP" === json.error.code || "E401" === json.error.code && json.error.detail.includes("--otp=<code>")) && !isCI__default.default) return null !== twoFactorState.token && (twoFactorState.token = null),

 if (shouldHandleOtp && ("EOTP" === (error = json.error).code || "E401" === error.code && error.detail.includes("--otp=<code>"))) return null !== twoFactorState.token && (twoFactorState.token = null),
 twoFactorState.isRequired = Promise.resolve(!0), internalPublish(pkgName, opts, twoFactorState);
 logger.error(`an error occurred while publishing ${pkgName}: ${json.error.code}`, json.error.summary, json.error.detail ? "\n" + json.error.detail : "");

}
@@ -490,6 +503,7 @@ async function internalPublish(pkgName, opts, twoFactorState) {
published: !1
};
}
var error;
return {
published: !0
};
diff --git a/dist/cli.esm.js b/dist/cli.esm.js
index ced46d2520d4bff71b94e4023b1841373a55712b..044d375056d5007859ee1a2e9c3dc7f0c1b4fcd2 100644
--- a/dist/cli.esm.js
+++ b/dist/cli.esm.js
@@ -682,31 +682,33 @@ function getCorrectRegistry(packageJson) {
return !registry || registry === "https://registry.yarnpkg.com" ? "https://registry.npmjs.org" : registry;
}

+const getPublishToolVersion = async (name, cwd) => (await spawn$1(name, ["--version"], {

cwd
+})).stdout.toString().trim();

async function getPublishTool(cwd) {

const pm = await preferredPM(cwd);
if (!pm || pm.name !== "pnpm") return {
name: "npm"
};

var _await$preferredPM;

try {
let result = await spawn$1("pnpm", ["--version"], {

 cwd

});
let version = result.stdout.toString().trim();
let parsed = semver.parse(version);
return {

 name: "pnpm",

 shouldAddNoGitChecks: (parsed === null || parsed === void 0 ? void 0 : parsed.major) === undefined ? false : parsed.major >= 5

};
} catch (e) {

const name = ((_await$preferredPM = await preferredPM(cwd)) === null || _await$preferredPM === void 0 ? void 0 : _await$preferredPM.name) || "npm";
const version = await getPublishToolVersion(name, cwd);

if (name === "yarn" && semver.lt(version, "2.0.0")) {
// Yarn Classic doesn't do anything special when publishing, let's stick to the npm client in such a case
return {

 name: "pnpm",

 shouldAddNoGitChecks: false

 name: "npm",

 version: await getPublishToolVersion("npm", cwd)

};
}

return {
name,
version
};
}

async function getTokenIsRequired() {

let publishTool = await getPublishTool(process.cwd());
if (publishTool.name === "yarn") return false;
// Due to a super annoying issue in yarn, we have to manually override this env variable
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633
const envOverride = {
@@ -731,6 +733,7 @@ async function getTokenIsRequired() {
}
function getPackageInfo(packageJson) {
return npmRequestLimit(async () => {
let publishTool = await getPublishTool(process.cwd());
info(npm info ${packageJson.name}); // Due to a couple of issues with yarnpkg, we also want to override the npm registry when doing
// npm info.
// Issues: We sometimes get back cached responses, i.e old data about packages which causes
@@ -738,7 +741,9 @@ function getPackageInfo(packageJson) {
// as they will always give a 404, which will tell publish to always try to publish.
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633

let result = await spawn$1("npm", ["info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json"]); // Github package registry returns empty string when calling npm info

let result = publishTool.name === "yarn" ? await spawn$1("yarn", ["npm", "info", packageJson.name, "--json"], {

env: Object.assign({}, process.env)

}) : await spawn$1("npm", ["info", packageJson.name, "--registry", getCorrectRegistry(packageJson), "--json"]); // Github package registry returns empty string when calling npm info
// for a non-existent package instead of a E404
if (result.stdout.toString() === "") {
@@ -793,20 +798,32 @@ let getOtpCode = async twoFactorState => {
}
return askForOtpCode(twoFactorState);
+};

+const isOtpError = error => {

// The first case is no 2fa provided, the second is when the 2fa is wrong (timeout or wrong words)

return error.code === "EOTP" || error.code === "E401" && error.detail.includes("--otp=");
}; // we have this so that we can do try a publish again after a publish without
// the call being wrapped in the npm request limit and causing the publishes to potentially never run

async function internalPublish(pkgName, opts, twoFactorState) {
let publishTool = await getPublishTool(opts.cwd);

let publishFlags = opts.access ? ["--access", opts.access] : [];

let shouldHandleOtp = !isCI && (publishTool.name === "yarn" ? semver.gte(publishTool.version, "3.2.0-rc.8") : true);
let publishFlags = publishTool.name !== "yarn" ? ["--json"] : [];

if (opts.access) {
publishFlags.push("--access", opts.access);
}
publishFlags.push("--tag", opts.tag);

if ((await twoFactorState.isRequired) && !isCI) {

if (shouldHandleOtp && (await twoFactorState.isRequired)) {
let otpCode = await getOtpCode(twoFactorState);
publishFlags.push("--otp", otpCode);
}

if (publishTool.name === "pnpm" && publishTool.shouldAddNoGitChecks) {

if (publishTool.name === "pnpm" && semver.gte(publishTool.version, "5.0.0")) {
publishFlags.push("--no-git-checks");
} // Due to a super annoying issue in yarn, we have to manually override this env variable
// See: https://github.com/yarnpkg/yarn/issues/2935#issuecomment-355292633
@@ -819,21 +836,35 @@ async function internalPublish(pkgName, opts, twoFactorState) {
code,
stdout,
stderr

} = await spawn$1(publishTool.name, ["publish", opts.cwd, "--json", ...publishFlags], {

} = publishTool.name === "yarn" ? await spawn$1("yarn", ["npm", "publish", ...publishFlags], {

cwd: opts.cwd,

env: Object.assign({}, process.env, envOverride)

}) : await spawn$1(publishTool.name, ["publish", opts.cwd, ...publishFlags], {
env: Object.assign({}, process.env, envOverride)
});
if (code !== 0) {

// NPM's --json output is included alongside the prepublish and postpublish output in terminal

// yarn berry doesn't support --json and we don't attempt to parse its output to a machine-readable format

if (publishTool.name === "yarn") {

 const output = stdout.toString().trim().split("\n") // this filters out "unnamed" logs: https://yarnpkg.com/advanced/error-codes/#yn0000---unnamed

 // this includes a list of packed files and the "summary output" like: "Failed with errors in 0s 75ms"

 // those are not that interesting so we reduce the noise by dropping them

 .filter(line => !/YN0000:/.test(line)).join("\n");

 error(`an error occurred while publishing ${pkgName}:`, `\n${output}`);

 return {

   published: false

 };

} // NPM's --json output is included alongside the prepublish and postpublish output in terminal
// We want to handle this as best we can but it has some struggles:
// - output of those lifecycle scripts can contain JSON
// - npm7 has switched to printing --json errors to stderr (https://github.com/npm/cli/commit/1dbf0f9bb26ba70f4c6d0a807701d7652c31d7d4)
// Note that the --json output is always printed at the end so this should work

let json = getLastJsonObjectFromString(stderr.toString()) || getLastJsonObjectFromString(stdout.toString());
if (json !== null && json !== void 0 && json.error) {

 // The first case is no 2fa provided, the second is when the 2fa is wrong (timeout or wrong words)

 if ((json.error.code === "EOTP" || json.error.code === "E401" && json.error.detail.includes("--otp=<code>")) && !isCI) {

 if (shouldHandleOtp && isOtpError(json.error)) {
   if (twoFactorState.token !== null) {
     // the current otp code must be invalid since it errored
     twoFactorState.token = null;

diff --git a/package.json b/package.json
index 0912d0f8fbf6f88c623ba4de0c87345947cde035..4ea6809033e063422e98cc3370685eb9b46847a2 100644
--- a/package.json
+++ b/package.json
@@ -57,7 +57,7 @@
"meow": "^6.0.0",
"outdent": "^0.5.0",
"p-limit": "^2.2.0",

"preferred-pm": "^3.0.0",

"preferred-pm": "^3.0.3",
"resolve-from": "^5.0.0",
"semver": "^5.4.1",
"spawndamnit": "^2.0.0",

Which works in yarn 4.0.0-rc.45 with these incantations in the package.json:
{
  "name": "package",
  "version": "0.0.0",
  "devDependencies": {
    "@changesets/cli": "patch:@changesets/cli<EMAIL_ADDRESS>  },
  "packageManager"<EMAIL_ADDRESS>  "resolutions": {
    "<EMAIL_ADDRESS>"patch:@changesets/cli<EMAIL_ADDRESS>  },
}

Any interest in picking this work back up? We love changesets at the Adobe Spectrum CSS project but we're leveraging yarn 4.1.1 and the workspaces:^ syntax and would love to see even a small update to using yarn npm publish instead of npm publish so that the workspace identifiers are correctly replaced in the released code.

any plan of this?

I would highly recommend switching to https://github.com/monoweave/monoweave for Yarn-based projects. I had a great experience with this tool in my monorepos.

waiting changesets support workspace:*

Hey @Andarist sorry for the ping, I got surprised by this pretty bad today 😅
Are you planning on picking this PR up again? Else, one option I can think of is just to remove changeset publish entirely, and delegate publishing logic to the package manager (could actually be the better way to go).

+1

Hey @Andarist, at my company we stumbled upon this issue a few weeks ago and it cost us quite some outages and bugs due to duplicate versions or incorrect resolutions in yarn.lock. I'm surprised to find out that this issue has been there since 2021. It hasn't been fixed and it is also not in the docs anywhere. It could have saved us a lot of headache to know that yarn publish isn't supported. In my opinion, this deserves a warning on your main README file.
Fortunately, we managed to fix this issue with the changes in this PR. So far I didn't get your feedback there. Could you let me know why isn't it an option to merge it?
Most importantly, if you are not fixing this issue, do you have at least a recommendation for people stuck in this problem? At my company, we chose changesets and are willing to help if the effort is manageable. Please let us know if there's anything we can do. And please document this because others should know before they choose this tool.

Would love to see this get landed. Could @transloadit sponsor this effort perhaps?

Is this an ai response? I actually offered to sponsor this. And we allocate 80% of revenue to open source at Transloadit

Is this an ai response? I actually offered to sponsor this. And we allocate 80% of revenue to open source at Transloadit

There are obviously more people visiting this PR than just yourself. While it is great to hear about how you help the open source community, this is not very common for companies, especially those where IT is not considered part of their core business, to do. I posted my message in the hopes that other frustrated developers that might come across this PR have a look at the presentation and reflect while we wait


Make CodeCracker localizable

When we started CodeCracker we were using the templates from Microsoft. At the time, they did not include a way to localize the library. It does now. Here are the localizable parts of an analyzer on the template now:
In diagnostics.cs:
// You can change these strings in the Resources.resx file. If you do not want your analyzer to be localize-able, you can use regular strings for Title and MessageFormat.
internal static readonly LocalizableString Title = new LocalizableResourceString(nameof(Resources.AnalyzerTitle), Resources.ResourceManager, typeof(Resources));
internal static readonly LocalizableString MessageFormat = new LocalizableResourceString(nameof(Resources.AnalyzerMessageFormat), Resources.ResourceManager, typeof(Resources));
internal static readonly LocalizableString Description = new LocalizableResourceString(nameof(Resources.AnalyzerDescription), Resources.ResourceManager, typeof(Resources));

In resources.resx:
  <data name="AnalyzerDescription" xml:space="preserve">
    <value>Type names should be all uppercase.</value>
    <comment>An optional longer localizable description of the diagnostic.</comment>
  </data>
  <data name="AnalyzerMessageFormat" xml:space="preserve">
    <value>Type name '{0}' contains lowercase letters</value>
    <comment>The format-able message the diagnostic displays.</comment>
  </data>
  <data name="AnalyzerTitle" xml:space="preserve">
    <value>Type name contains lowercase letters</value>
    <comment>The title of the diagnostic.</comment>
  </data>

We need to update all analyzers so strings are localizable, and then start a localization initiative.
Note: Code fix providers don't have localization on the template, but I believe we can use the same strategy.

@code-cracker/owners We need to discuss this.

@code-cracker/owners @code-cracker/owners First analyzer is up with an example on how to write an analyzer and code fix with localization. See NameOfAnalyzer and NameOfCodeFixProvider. Also, look on the Resources, using Visual Studio, on the Common Project:

We have updated the definition of done and now all analyzers will need to be made with LocalizableResourceString for all text fields that the user will see.
This issue will remain opened until we fix the already complete analyzers and fixers.

If the resources are in common, we need to be careful how the wording will work across both the C# and VB projects. For example, in the screenshot supplied, the NameOfAnalyzer_Description is applicable in C#, but is incorrect for VB which should be in VB 14, the NameOf() operator ... Some resources can be shared between projects, but not all. We need to consider how to handle both scenarios correctly.

If they are specific for C#, they should be moved to the C# project resources. But I think we can rewrite this specific one to be more language agnostic. If it does not hurt expressiveness, then I believe that is the way to go.

Good job @giggio

Pull request #582 added the first example of localization to CodeCracker!


feat: enable py.typed

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 13.51%. Comparing base (faf7a38) to head (600a254).
Report is 6 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##            main      #95      +/-   ##
=========================================
+ Coverage   6.36%   13.51%   +7.15%
=========================================
  Files         77       77
  Lines       6630     6644      +14
=========================================
+ Hits         422      898     +476
+ Misses      6208     5746     -462

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fill the docs with other crud operations

currently there is only an example with a reading operation.

partially filled by https://github.com/Mazuh/resource-toolkit/commit/9006a6df421c575d9cc617c0e9344168cacbed87


[SPARK-13576] [build] [test-maven] Don't create assembly for examples.

As part of the goal to stop creating assemblies in Spark, this change
modifies the mvn and sbt builds to not create an assembly for examples.
Instead, dependencies are copied to the build directory (under
target/scala-xx/jars), and in the final archive, into the "examples/jars"
directory.
To avoid having to deal too much with Windows batch files, I made examples
run through the launcher library; the spark-submit launcher now has a
special mode to run examples, which adds all the necessary jars to the
spark-submit command line, and replaces the bash and batch scripts that
were used to run examples. The scripts are now just a thin wrapper around
spark-submit; another advantage is that now all spark-submit options are
supported.
There are a few glitches; in the mvn build, a lot of duplicated dependencies
get copied, because they are promoted to "compile" scope due to extra
dependencies in the examples module (such as HBase). In the sbt build,
all dependencies are copied, because there doesn't seem to be an easy
way to filter things.
I plan to clean some of this up when the rest of the tasks are finished.
When the main assembly is replaced with jars, we can remove duplicate jars
from the examples directory during packaging.
Tested by running SparkPi in: maven build, sbt build, dist created by
make-distribution.sh.
Finally: note that running the "assembly" target in sbt doesn't build
the examples anymore. You need to run "package" for that.

Test build #52261 has started for PR 11452 at commit d0d4304.

I think there's some slight overlap between this and #11178, so it would be great if you could also review that PR.

Test build #52261 has finished for PR 11452 at commit d0d4304.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      checkArgument(!isExample || mainClass != null, \"Missing example class name.\");

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52261/
Test FAILed.

Hmm, looks like forcing jars to be exported (instead of the generated classes directory) broke some tests...

Test build #52330 has started for PR 11452 at commit 8263ed5.

Test build #52330 has finished for PR 11452 at commit 8263ed5.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52330/
Test PASSed.

So would anybody care to take a look at this? @srowen? @JoshRosen?

Test build #52672 has started for PR 11452 at commit ccdd2b7.

I like the cleanup. I don't feel strongly about the change either way, but I also think there's not much value in offering example assembly JARs. They're really source code examples.

but I also think there's not much value in offering example assembly JARs

I think it's nice to be able to run a quick Spark app at least to know things are working, although spark-shell can be used for most of those cases.
One future enhancement would be to get these examples out of the main tarball distributions. They're rather large, because of all the dependencies, so that would reduce the package sizes considerably.

Test build #52672 has finished for PR 11452 at commit ccdd2b7.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52672/
Test PASSed.

Test build #52933 has started for PR 11452 at commit fda639b.

Test build #52933 has finished for PR 11452 at commit fda639b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52933/
Test PASSed.

retest this please

Test build #52959 has started for PR 11452 at commit fda639b.

Test build #52959 has finished for PR 11452 at commit fda639b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52959/
Test FAILed.

SQL test failure, I assume unrelated? retest this please

Test build #52969 has started for PR 11452 at commit fda639b.

Test build #52969 has finished for PR 11452 at commit fda639b.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52969/
Test PASSed.

Test build #53081 has started for PR 11452 at commit 4e3d390.

I plan to merge this after tests pass.

Test build #53081 has finished for PR 11452 at commit 4e3d390.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
abstract class NativeDDLCommand(val sql: String) extends RunnableCommand
case class CreateDatabase(
case class CreateFunction(
case class AlterTableRename(
case class AlterTableSetProperties(
case class AlterTableUnsetProperties(
case class AlterTableSerDeProperties(
case class AlterTableStorageProperties(
case class AlterTableNotClustered(
case class AlterTableNotSorted(
case class AlterTableSkewed(
case class AlterTableNotSkewed(
case class AlterTableNotStoredAsDirs(
case class AlterTableSkewedLocation(
case class AlterTableAddPartition(
case class AlterTableRenamePartition(
case class AlterTableExchangePartition(
case class AlterTableDropPartition(
case class AlterTableArchivePartition(
case class AlterTableUnarchivePartition(
case class AlterTableSetFileFormat(
case class AlterTableSetLocation(
case class AlterTableTouch(
case class AlterTableCompact(
case class AlterTableMerge(
case class AlterTableChangeCol(
case class AlterTableAddCol(
case class AlterTableReplaceCol(
case class In(attribute: String, values: Array[Any]) extends Filter

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53081/
Test FAILed.

retest this please

Test build #53098 has started for PR 11452 at commit 4e3d390.

Test build #53098 has finished for PR 11452 at commit 4e3d390.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
abstract class NativeDDLCommand(val sql: String) extends RunnableCommand
case class CreateDatabase(
case class CreateFunction(
case class AlterTableRename(
case class AlterTableSetProperties(
case class AlterTableUnsetProperties(
case class AlterTableSerDeProperties(
case class AlterTableStorageProperties(
case class AlterTableNotClustered(
case class AlterTableNotSorted(
case class AlterTableSkewed(
case class AlterTableNotSkewed(
case class AlterTableNotStoredAsDirs(
case class AlterTableSkewedLocation(
case class AlterTableAddPartition(
case class AlterTableRenamePartition(
case class AlterTableExchangePartition(
case class AlterTableDropPartition(
case class AlterTableArchivePartition(
case class AlterTableUnarchivePartition(
case class AlterTableSetFileFormat(
case class AlterTableSetLocation(
case class AlterTableTouch(
case class AlterTableCompact(
case class AlterTableMerge(
case class AlterTableChangeCol(
case class AlterTableAddCol(
case class AlterTableReplaceCol(
case class In(attribute: String, values: Array[Any]) extends Filter

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53098/
Test FAILed.

This is failing a sql job that seems unrelated to this change.
Exchange SinglePartition, None
+- WholeStageCodegen
   :  +- TungstenAggregate(key=[], functions=[(count(1),mode=Partial,isDistinct=false)], output=[count#3206L])
   :     +- Scan org.apache.spark.sql.execution.datasources.text.DefaultSource@332a5bae part: struct<>, data: struct<value:string>[] InputPaths: file:/home/jenkins/workspace/SparkPullRequestBuilder%403/sql/core/target/scala-2.11/test-classes/text-suite.txt

	at test.org.apache.spark.sql.JavaDataFrameSuite.testTextLoad(JavaDataFrameSuite.java:321)
Caused by: java.io.IOException: No input paths specified in job
	at test.org.apache.spark.sql.JavaDataFrameSuite.testTextLoad(JavaDataFrameSuite.java:321)

retest this please

retest this please

Test build #53118 has started for PR 11452 at commit 19312fe.

Test build #53118 has finished for PR 11452 at commit 19312fe.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public class ShuffleServiceHeartbeat extends BlockTransferMessage

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53118/
Test FAILed.

Merged build finished. Test FAILed.

retest this please

Test build #53124 has started for PR 11452 at commit 19312fe.

Test build #53124 has finished for PR 11452 at commit 19312fe.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public class ShuffleServiceHeartbeat extends BlockTransferMessage

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53124/
Test PASSed.

Merged build finished. Test PASSed.

Yay! Merging to master.

Test build #53153 has started for PR 11452 at commit e9ab003.

Test build #53153 has finished for PR 11452 at commit e9ab003.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/53153/
Test PASSed.

Merged build finished. Test PASSed.

Merging to master.


when a player gets weaken cast on them they drop items to the ground

When you get weakened / cursed and your strength becomes too low for items you are already wearing, you will unequip them, but since you can't put them in your bag they drop to the ground. You should not unequip work items after being weakend below the streq.

Afair, every item has always been unequipped if char went below strreq, it should be the desired behavior

If it doesn't throw the items to the ground , that i can confirm has never been how it works. Players are quite irritated by it as well

But are they overloaded or not?
Il dom 3 mar 2019, 08:46 soulless320<EMAIL_ADDRESS>ha scritto:

If it doesn't throw the items to the ground , that i can confirm has never
been how it works. Players are quite irritated by it as well
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Sphereserver/Source-experimental/issues/245#issuecomment-468997920,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOWhJKOD94kQ_J8VqidoMWOIP93Yq_Yzks5vS33xgaJpZM4bVNKq
.

They are overloaded, but it never drops the stuff to the ground, it should be placed inside the pack

So, it seems that the current behavior has been added on 56c (on 56b items were dropped in the pack if you already carried them). I think we may add an option flag

I think that would be good. The default should be the pack, but either way as long as we control it I would love it, this is a very frustrating thing to have happen when you are weakened and no one's expecting it to happen :O

Good to go, thank you Nolok, sorry for the late reply!


Move documentation to .md files

Due to vaccation postponing this to the next sprint.

Add some info about how to actually start using WAW after cloning the repo.

Requirements must be installed with pip2.7 and with admin privileges.

Update watson api url in config templates.


Nested tuple input

Currently nested tuple is perhaps the most complex input we allow from the interface, without having ot use raw. Right now nested tuple is misbehaved for R. eg:
n: (100, (200,300)), (400, 500, 600)

The first one is nested tuple, which will cause problem in R. We should specifically "flatten" tuples in R, eg make it (100,200,300), before passing to R, or try harder with c(100,c(200,300))  But the problem remains that queries will be inconsistent -- that in one setting n has 3 elements and another has 2 elements. There may be user cases for this, but DSC query will have difficulty deciding whether to split to 2 or to 3 elements.

A cleaner solution would be disable nested tuple, and support only up to tuple level. We will flatten whatever inside tuples. I personally use nested tuples heavily in Python, but I assume that's when I will have to use raw instead for interface to my Python codes.

@gaow A tuple in Python seems like a very complicated data structure; I suggest that tuples (or lists in R) need to be defined using raw(). Otherwise, I see this raising a lot of confusion and errors.

Great, let's use raw for it.

@gaow But vectors are allowed, right? (i.e., non-nested tuples in which each element is a character, numeric or logical?

@pcarbo Yes, I guess we should say we support objects that returns True for R's is.atomic() ?

@gaow Yes, I think that is a reasonable approach. More precisely, an object x can be defined in DSC without raw if and only if is.atomic(x) & !is.null(x) is TRUE. Correct?

I think this is the intention, at least. I will have to create unit tests for various representations for missing value though I think my code intended to deal with them properly ..


Journal names need to support auto complete when users are typing journal name in

also need so retain the typed in journal name, currently it gets cleared off.

@htpvu neither of these happen on my copy of develop. Can you elaborate on what you did, what you expected to happen, and what happened, so I can try to reproduce the error?

I didn't give the application a DOI, i just started to type in a Title and Journal Name. One of our usecases is the submission of some publication with out DOI, so users need all the help they can get from the application to fill out information.

@htpvu, @cameronblandford and I have tested this and this issue seems to be solved now. moving this to done awaiting review.

verified rev. d3c7797f


could you publish your detection metric?

could you publish your detection metric? mAP, AP per class?
As a end-to-end method, i very want to know the detection performance.
Also, the minADE relay on the matched detection and GT. Without mAP, it is difficult to compare with other model with different mAP.

We tested the tracking metric instead of the detection metric. The detection classes and tracking classes are different in nuScenes dataset. To calculate AP per class, you may download the checkpoint and use it to generate the detection results.


Refinement of PKCE

The only effective change is that PKCE handshake tokens will have been generated if an authorization URL is constructed. This is important because it avoids an unexpected error from Spotify.
Other changes include:

New public method SpotifyPKCE.parse_auth_response_url, simply executes the parallel method from SpotifyOAuth
SpotifyPKCE._get_auth_response_interactive now calls a static method from self rather than SpotifyOAuth
The SpotifyImplicitGrant security advisory now reflects the addition of SpotifyPKCE

@stephanebruckert I am prepared to add a warning to the initialization function of SpotifyImplicitGrant. Do we want to put it in, or just leave the advisory in the docstr?

Looks good to me, merging!
Yes adding the warning is a good idea https://github.com/IdmFoundInHim/spotipy/pull/27, please open that PR here 👍


Presenter notes font color should default to black

My presentation has a black background and white font. When I add presenter notes, the font color of the notes is white, which does not show up well in the presenter screen, which uses a light grey background color. Since the presenter screen background color is hardcoded, the font color should default to black, which would allow it to be changed inline as needed (highlighting, etc). I have worked around this with:
MD:
???
.black[Here are the presenter notes]

CSS:
.black {
  color: #000000;
}

Good point. Fix will be included in nest release; 0.11.

Version 0.11 which fixed this has now been released.


Support for Dokka in the JavaDoc integration

Request details
Currently, if a .jar file ends with -javadoc.jar, it can be viewed through the Reposilite web UI. Trying to do this with a -dokka.jar, Kotlin's documentation engine doesn't seem to work. Is it possible for the JavaDoc detection to include files ending with -dokka.jar? Or would more support need to be added to support Dokka due to a different file structure?

I honestly don't know, as I never used Dokka 😅 But yeah, it makes sense to support it at some point.

I honestly don't know, as I never used Dokka 😅 But yeah, it makes sense to support it at some point.

I wonder if it would work if we just changed the artifact ID to end with -javadoc.jar

I honestly don't know, as I never used Dokka 😅 But yeah, it makes sense to support it at some point.

I wonder if it would work if we just changed the artifact ID to end with -javadoc.jar

Not quite. Reposilite's access control breaks some stuff and things don't render properly.

I honestly don't know, as I never used Dokka 😅 But yeah, it makes sense to support it at some point.

I wonder if it would work if we just changed the artifact ID to end with -javadoc.jar

Not quite. Reposilite's access control breaks some stuff and things don't render properly.

Oh cool! Thank you so much for the PR! I'd love Dokka support so much, our team could really use it

Ok, scratch ALL of that, I found the issue.

Dokka by default generates a HTML documentation, so it's only a static-site serving task.
However it can also output in javadoc format and Markdown. The later requires a markdown engine in the frontend, if we wish to support all formats.
See HTML format here (sorry for redaction, don't wanna plug other projects):


Try enable TORCH_NCCL_AVOID_RECORD_STREAMS

From llama 405b paper:

We enable TORCH_NCCL_AVOID_RECORD_STREAMS to reduce memory usage from asynchronous point-to-point
communication.

More reading: https://discuss.pytorch.org/t/cuda-allocation-lifetime-for-inputs-to-distributed-all-reduce/191573

This didn't have any impact on things


Create project quick start

Make it easier for people to start their own trading application using roboquant. Especially for people new to Kotlin and the JVM eco system, this might make it easier to get up to speed.
One possible solution is to create and publish a Maven Archetype. But could also be something similar using Gradle.

Created a repo with the first version of the Maven Archetype: roboquant-quickstart

is in place


Fix FileNotFoundError for log file

Closes #601
Add force=True in logging.basicConfig under setup_custom_logger() to clear root handlers and avoid sharing file references in between runs
Update move_log_to_prov_dir()
Add module level instantiation of logger in logger.py to avoid repeating logger outputs in move_log_to_prov_dir()

Thanks for the review @chengzhuzhang and pointing out that some log lines are repeated. Yes, we can figure out why this is happening in a new issue/PR (can be caused by different reasons like for loops, log handlers repeating the same lines, etc.).
I'll merge once the build passes.


Bot Management Dashboard

This ticket covers engineering and design task to build a Bot Management Dashboard view that gives an overview of all bots currently running in Composer. It gives us ability to Start, Stop, Restart, open bots in Emulator and Composer

Closing this issue as we are going again the model of a centralized dashboard showing status of bots. We will be going with .botprojects file that shows the relationship between root bot and its skills


The output parameters are too small and add user customized threshold?

Hi Maxime,
Hope you are doing well!
Would it be possible for you to add a user-customized threshold for the fitting process? Sometimes I found the default threshold 5e-4 couldn't raise any results for my EIS data. Thus, I think if we can customize that fitting threshold by using an additional argument of the evolution function, that would be great.
Another issue I noticed is the evolution function sometimes give me super small component value (such as 1e-18). Would it be possible to add an argument of the evolution function so that we can control the possible ranges of different types of components?
For the circuit_optimization function, I noticed you added some additional arguments. That's really fantastic. Would it be possible for us to fix (or set initial values of) only one (or several) circuit components instead of setting them all? I noticed the current arguments require the same length of the number of components.
For example: if I want to optimize the parameters for R1-P2-[R3,P4], with the current argument, I need to set x0 = [10,10,0.5,10,10,0.5]. I wonder if I can only pass something like R1_initial = 10 but don't set other components?
Thank you so much for your generous contribution to this awesome package. This is really FANTASTIC!!!
Best,
Runze

Hi Runze,
Glad to receive feedback from you. These are all excellent suggestions, particularly adjusting the convergence threshold.
I will be making several updates to this package next week, and your suggestions are included in the list.
Best regards,
Maxime

Hi Runze,
An optional argument, convergence_threshold, has been added so that the default value of 4e-5 can be adjusted. A dictionary of parameter bounds can now be input in the circuit_evolution function in the optional argument bounds. An example of such a dictionary is:
Dict('R'=>[0,1.0e9],'C'=>[0,10],'L'=>[0,5],'P'=>[[0,0],[1.0e9,1]]).
Finally, you can fix a single component value in the parameter_optimisation function by using the fixed_params argument. This argument should be a tuple containing a list of the component indices to be fixed and their respective values. For example, if you wish to fix only the first resistor of R1-P2-[R3,P4] to 10, this can be done as follows:
parameteroptimisation("R1-P2-[R3,P4]", measurements,frequencies,fixed_params = ([1],[10]).
These updates have been added to the repo; I'll do some testing and make some other adjustments before they are included in the next release of this package.
Best regards,
Maxime


Integrate chocolatey package with the build script

A Chocolatey package now exists for the extension, having been created using the binaries from the 3.5 release. We need to now integrate the creation of the package with the build script for the extension.
See nunit/nunit-console#253 and nunit/nunit-project-loader#8 for more info.

@NikolayPianikov My default assumption is that it will be done just like the others, but since you are the maintainer of this package, it's basically up to you. The main points of the implementation as I have done it elsewhere are as follows:

There are no nuspec files. Instead the nupkg is generated in the cake script. This allows constants to be used so that both packages (nuget and chocolatey) use the same values for fields like description, summary, etc. Of course, each one is also tailored to conform to the different conventions of the nuget.org and chocolatey.org and they have different ids.

The script allows repackaging without rebuilding, including specifying the binary source directory and the nuget or chocolatey package version to produce. This helps when the binaries are correct but there is an error in package format. Packaging depends on build but repackaging does not.

It's an error to build if an alternate source is provided. That's because the built binaries would not be in the packages produced.

If you see any problem in the approach, let me know. You can tell me now or after I do a PR, whichever is easier.

@CharliePoole Common approach is better from my point of view. But just for thinking, we could think about how it works for the VS 2017 project model and targets, I mean dotnet pack or msbuild /t:pack and so on

@NikolayPianikov I'm currently building all the extensions in VS2015. Probably the best way to deal with this is for me to get in my basic changes and then have you review and suggest more steps. If we do more, it will eventually be migrated back to the other extensions.
I tried to build and it failed. You are referencing a CI build of the 3.5.0 engine API that no longer exists. I'll change the references to a released version, which will fix one of the other issues.

Regarding the VS2017 model, it seems that the Cake nuget and chocolatey commands are supposed to hide that from us - i.e. it should work for both versions of VS transparently.

@NikolayPianikov Do you normally have a failure on the Travis CI build?

@CharliePoole sometimes when tests check agent's processes they are still in memory :(

Should we do a new release? If so, what should be the version number?
The version could be either 1.0.3 or 1.1.0. Since you have a 1.0.3 milestone, I added it there but we could change it. There is already a 1.0.2 chocolatey package that I created using the same binaries as the 1.0.2 nuget package, so it could wait till you are ready to do a new release. Once you release, then it's up to the engine team to decide whether to include the new package in the bundles they produce, so we will need to create an issue for them to do that. What would you like to do?

We haven't done any significant changes, so I think the new release is not needed. What I should do to use current version of extension?

Not sure what you mean by "what should I do".
Users can download the current release (1.0.2) from either nuget or chocolatey. It will also be incluced in the new nunit-console-with-extensions chocolatey package when I release it.
If you create a new release of the extension and you want it to be included in the next release of the package by the engine team, then you would create an issue on the nunit-console repo. Since you already test everything, I assume it would be accepted immediately.


broken typescript definition

Hi all, currently typescript definition seems broken, typescript compiler complains about malformed type definition file (.d.ts) syntax.
maybe it's off topic, I love this package. so i've migrated async-sema package to typescript. i'd like to discuss about publishing typescript version of async-sema. should i publish typescript version of async-sema package as individual package? or just send PR to this repo? Please kindly give me your advice. Thanks :)

I'd prefer fixing the type definitions but I'm open to alternative solutions. The most important thing to me is that I can install this from npm and it works with the latest Node.js.

@OlliV installed from fork:
"async-sema": "https://github.com/dsabanin/async-sema",


Fit NeRO for Blender Dataset; Add dataset_dir in config files;

Thank you very much for your contribution for adding support for the nerf-blender datasets!
Would you mind if I update it to another branch and mention it in the markdown?

Thank you for your appreciation. I am glad to hear that my contribution towards adding support for the blender datasets has been beneficial.
As for your request, I have no objections at all. Feel free to update it to another branch. I'll write a README right now.

I have already add README for running the Blender Dataset. This branch is compatible with the original NeRO dataset.

Hi, it seems that there are some conflicts here so I cannot merge and rebase it to another branch. Maybe, you need to pull my updates and resolve them. I didn't update any essential codes yet.

Hi, I have already pull your updates in the main branch before. The pull request step shows that there are no conflicts and it can be merged. How can I help you with the merge?

Hi, I've figured out how to merge into another branch. Thanks for your efforts!


Set tests to error on uncaught warnings

Closes #166

I rebased this PR on main, the tests fail because of the following warning:
UserWarning: Rewrite warning: The Op i0 does not provide a C implementation. As well as being potentially slow, this also disables loop fusion.

i0 seems to be the modified Bessel function of the first kind of order 0 (https://github.com/aesara-devs/aesara/blob/a1739f6c56f018d3c5508cd67e0e9a35617f66d6/aesara/tensor/math.py#L1402). Do we want a C implementation for this in Aesara or should we just ignore the warning?

Do we want a C implementation for this in Aesara or should we just ignore the warning?

Ideally, we would have a C implementation, but we should simply catch/ignore acceptable warnings like this using pytest.warns or something similar.


More explicit warning for <transition> inner component with fragment root

Version
3.0.0-rc.5
Reproduction link
https://github.com/dani17r/vue-3-beta-pruebas

Steps to reproduce
When opening the web, try the change of routes, when clicking on the links, the problem will be displayed in the browser console.
What is expected?
I expected it to run the transition on the components no matter if they were fragmented
What is actually happening?
apparently the  component does not allow calling the component with multi-root nodes

I just wanted to test vue 3 with vuex   vue-router, and when I put transitions in  I came across this surprise of chunky elements not allowed in  tag

Possible duplicate of #1782

@yyx990803 If it helps, I found that the problem is not with the transitions or the  tags. The problem really is in the

If you want to use a transition component, its content must have one single root to apply the classes

Oh that's true, yeah transition does require its inner component to have single roots. We should probably have a better warning for this case.

they should allow, what: <ruter-view> <transition: name =" .. "> <keep-alive> <component: is =" ... "> <k ../> <t ../> < r ../> can use the (fragments) in the components, it's more or less like there are no multiple roots in vue 3 when using components with  inside

If you want to have transition then the component being transitioned must have a single root.

OK, so how should we give our elements a single root?  It would be nice to have <></> or some sort of fragment we can use without wrapping everything in additional divs.


TypeMismatchException when delta has a new field in struct.

Hi there,
Got the following error when reading a delta table,
TypeMismatchException: Mismatch Type Error: Type
STRUCT(a VARCHAR, b VARCHAR, c VARCHAR) does not match with
STRUCT(a VARCHAR, b VARCHAR, c VARCHAR,
       d VARCHAR).
Cannot cast STRUCTs of different size

I compare the table schema, it indeed has a new filed in this struct.
It looks very similar to https://github.com/duckdb/duckdb/issues/7734, it's fixed for python, not sure it should be fixed in duckdb or delta side?
Thanks

Thanks for reporting @mervynzhang this is a known issue at the moment and is something we are working on!


Error when deleting Resource Locks via az lock delete galleries/GALLERYNAME/images/IMAGEDEF/verions/n.n.n

This is autogenerated. Please review and update as needed.
When attempting to delete a resource lock created successfully from the Portal for an image definition version, an error is encountered:
az resource lock delete --resource-name /subscriptions//resourceGroups/RESOURCE-GROUP/providers/Microsoft.Compute/galleries/GALLERY-NAME/images/IMAGEDEF-NAME/versions/n.n.n.n/providers/Microsoft.Authorization/locks/LOCKNAME --resource-group RESOURCE-GROUP --resource-type Microsoft.Compute/galleries
Error:
The command failed with an unexpected error. Here is the traceback:
No value for given attribute
Traceback (most recent call last):
File "/usr/lib64/az/lib/python3.9/site-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 663, in execute
raise ex
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 726, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 697, in _run_job
result = cmd_copy(params)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 333, in call
return self.handler(*args, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
return op(**command_args)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/resource/custom.py", line 3173, in delete_lock
return lock_client.management_locks.delete_at_resource_level(
File "/usr/lib64/az/lib/python3.9/site-packages/azure/core/tracing/decorator.py", line 73, in wrapper_use_tracer
return func(*args, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/resource/locks/v2016_09_01/operations/_operations.py", line 1284, in delete_at_resource_level
request = build_management_locks_delete_at_resource_level_request(
File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/resource/locks/v2016_09_01/operations/_operations.py", line 342, in build_management_locks_delete_at_resource_level_request
"lockName": _SERIALIZER.url("lock_name", lock_name, 'str'),
File "/usr/lib64/az/lib/python3.9/site-packages/msrest/serialization.py", line 652, in url
output = self.serialize_data(data, data_type, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/msrest/serialization.py", line 760, in serialize_data
raise ValueError("No value for given attribute")
ValueError: No value for given attribute
The following attempt to create a lock for an Image Gallery Version also fails:
az resource lock create --lock-type ReadOnly -n  -g  --resource /subscriptions//resourceGroups//providers/Microsoft.Compute/galleries//images//versions/n.n.n --resource-type Microsoft.Compute/galleries/images/versions
The command failed with an unexpected error. Here is the traceback:
No value for given attribute
Traceback (most recent call last):
File "/usr/lib64/az/lib/python3.9/site-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 663, in execute
raise ex
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 726, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 697, in _run_job
result = cmd_copy(params)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/init.py", line 333, in call
return self.handler(*args, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
return op(**command_args)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/resource/custom.py", line 3213, in create_lock
return lock_client.management_locks.create_or_update_at_resource_level(
File "/usr/lib64/az/lib/python3.9/site-packages/azure/core/tracing/decorator.py", line 73, in wrapper_use_tracer
return func(*args, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/resource/locks/v2016_09_01/operations/_operations.py", line 1198, in create_or_update_at_resource_level
request = build_management_locks_create_or_update_at_resource_level_request(
File "/usr/lib64/az/lib/python3.9/site-packages/azure/mgmt/resource/locks/v2016_09_01/operations/_operations.py", line 291, in build_management_locks_create_or_update_at_resource_level_request
"resourceProviderNamespace": _SERIALIZER.url("resource_provider_namespace", resource_provider_namespace, 'str'),
File "/usr/lib64/az/lib/python3.9/site-packages/msrest/serialization.py", line 652, in url
output = self.serialize_data(data, data_type, **kwargs)
File "/usr/lib64/az/lib/python3.9/site-packages/msrest/serialization.py", line 760, in serialize_data
raise ValueError("No value for given attribute")
ValueError: No value for given attribute
ASK:
-How do we create and delete locks for Azure Compute Gallery Definitions in az cli using az lock create -or az resource lock create?
Command Name
az lock delete
Errors:
Unexpected --namespace for lock LOCKNAME expected Microsoft.Compute

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az lock delete --name {} --resource-group {} --resource {} --resource-type {}

Expected Behavior
Environment Summary
Linux-5.4.0-1091-azure-x86_64-with-glibc2.35 (Cloud Shell), CBL-Mariner/Linux
Python 3.9.13
Installer: RPM

azure-cli 2.40.0

Extensions:
vm-repair 0.4.1
image-copy-extension 0.2.9
serial-console 0.1.2
ai-examples 0.2.5
ml 2.7.1
ssh 1.1.2

Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.1.0b1

Additional Context

@zhoxing-ms for awareness

Update:
We are successfully with the following PowerShell Command - can we have the syntax for the az cli equivalent please?
New-AzResourceLock -LockLevel CanNotDelete -LockName LOCKSIGVERSION -ResourceName "AZCOMPUTEGALLERY/IMAGEDEF2/1.1.1" -ResourceType "Microsoft.Compute/galleries/images/versions" -ResourceGroupName UKSOUTH

@johnem-msft
Please use command az resource lock delete -n {lock_name} --resource {image_version_name} -g {resource_group} --resource-type Microsoft.Compute/versions --parent galleries/{image_gallery_name}/images/{image_definition_name} to delete locks on gallery image version

Thanks so much Xing Zhou!!
I confirmed that I was able to list a lock created via gui via:
az lock list
and then use that info to delete the log - eg:
az resource lock delete -n LOCKSIGVERSIONLOCKNAME --resource "1.1.1" -g UKSOUTH --resource-type Microsoft.Compute/versions --parent galleries/AZCOMPUTEGALLERYNAME/images/IMAGEDEFNAME
In the same fashion I was also able to recreate the lock as follows:
Create Azure Compute Gallery Version Lock via Az CLI:
az resource lock create -n LOCKSIGVERSIONLOCKNAME --resource "1.1.1" -g UKSOUTH --resource-type Microsoft.Compute/versions --parent galleries/AZCOMPUTEGALLERYNAME/images/IMAGEDEFNAME --lock-type CanNoteDelete
az lock list confirms successful creation as well.

If there are no other questions, I will close the issue first. If you have other questions in the future, please feel free to contact us


add instruction to start docker before running npx

Besides docker there is podman which is a light weight solution and is much better in many scenarios.

Thanks!


Add a "style guide" to the documentation

Kind of PEP 8-ish or perlstyle-oid.
Needless to say, this would go really well together with the idea of a prettier-style tool, already outlined in https://github.com/masak/007/issues/14#issuecomment-149211379.

Going to block this one on #385, because I don't want it to scope-creep.


Fix memory leaks in custom executor

When one calls elog(ERROR,... it longjmp out of the current stack leaving no chance for the C++ to be executed.
This PR is a first iteration toward what we want to rationalize (cf. https://github.com/duckdb/pg_duckdb/issues/93 ):

keep a function with a pure C++ "flavor" (object creation, exceptions, etc.)
call it in a new wrapper that copies out the error message and uses PG mechanism to throw the error

This fixes https://github.com/duckdb/pg_duckdb/issues/120, even though there still seem to be a small leak with DuckDB's PrepareQuery leftover (to be followed-up separately)

Tests are still failing it seems after merging with main.

Yeah sorry should have kept this in draft - I'm still working on it; this is a simple revert


Could not find target

Hi,
I tried to setup a new pdk (by creating a new target at first) but facing this error when I run the heartbeat-example with the new target:
siliconcompiler.core.SiliconCompilerError: Could not find target pdk_demo
pdk_demo.py is the target which I created in siliconcompiler/siliconcompiler/targets
Any solution for this?
Thanks
Nils

@techstuds what version of siliconcompiler are you using? If there is a syntax error in pdk_demo it might fail to import.
In the most recent version 0.11.0 you can do:
from siliconcompiler.targets import pdk_demo

.....

chip.load_target(pdk_demo)

Thank you @gadfort, this worked (version 0.11.0).


Markdown: Create link when pasting URL over highlighted text

I'm starting to see more and more text editors implement this helpful feature.

Copy URL to clipboard
Highlight a word in a Markdown file
Paste

The word should be replaced with a link. e.g., slashdot should become [slashdot](https://slashdot.org)

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

@mjbvz I did search before opening this, and didn't see one. What issue is this a duplicate of?


Available in the app store?

@ladrua I found your app in a discussion of the owncloud iOS-app. In the meantime the owncloud-team split up and created a fork. Unfortunately, they can't fork and distribute their own iOS-client. In the meantime, they use a third-party closed-source app (https://nextcloud.com/nextcloud-9-update-brings-security-open-source-enterprise-capabilities-and-support-subscription-ios-app/). I'm not sure if this is the way to go and perhaps a chance to find a proper solution.
Is a version of this app available in the app-store? I'd like to give it a try.

I'm afraid it's not available in the appstore, and it's currently not working for lates iOS version. The codebase is getting a bit old, and am considering a rewrite as oppose to trying to fix it. On a side note, I just tried the 3d party app for Nextcloud, and they have a lot of nice features. Upload all photos, auto sync and so forth. These are features that this my app cant handle attm, and are really nice. Still there should be an opensource themable app for nextcloud/owncloud.

That's a pitty. I was looking for some other forks of the TeamDisk-app but nothing was available on the iOS store.

Still there should be an opensource themable app for nextcloud/owncloud.

I agree on that.


Add cross compilation support for Darwin

CAN'T BE MERGED BEFORE https://github.com/sorbet/bazel-toolchain/pull/10
This PR is the second attempt of #8152
Instead of using the original approach of compiling a native ARM64 binary and an x86 binary through rosetta (which is this PR's first commit), this PR adds support for cross compiling x86 -> arm64 and vice versa.
The major advantage of this approach is that we always use the Bazel installation native to the machine's architecture, instead of needing to remove and re-download so that we can swap between native vs rosetta version.
Details
The implementation follows the steps outlined in toolchains_llvm documentation. Essentially, we need to define the sysroot for the different architectures that we want to cross compile to. It's a bit odd because on MacOS, the sysroot is always the MacOS SDK regardless of which target you're trying to compile to, but that's the only way toolchains_llvm will allow you to cross-compile.
Then we define configurations for cross compiling in both directions in .bazelrc. The buildkite release script will now use those configurations to produce both binaries.
Test plan
We were able to manually test cross compilation from arm64 -> x86, which produces a working x86 binary. However, we don't have an x86 Darwin machine, so maybe we can test it on CI?

@froydnj

The static-release script is taking a very long time on our OS X machine

Do you have any output showing where the build is stuck?

Also, the build-static-release.sh script ends with: cp bazel-bin/main/sorbet _out_/$platform/

Yes, I think we can remove this change and just create the universal binary at bazel-bin/main/sorbet

@froydnj

The static-release script is taking a very long time on our OS X machine

Do you have any output showing where the build is stuck?

https://buildkite.com/sorbet/sorbet/builds/32590#0191fc8b-c0b0-4bb7-8dbf-cdb5873533c3
Jake said the machine wasn't really doing anything interesting.

Also, the build-static-release.sh script ends with: cp bazel-bin/main/sorbet _out_/$platform/

Yes, I think we can remove this change and just create the universal binary at bazel-bin/main/sorbet

I asked that we not create it under bazel-bin/main/sorbet in #8152 (apparently Github ate my comment?) because bazel-bin/ is Bazel's domain, not ours, and we're not supposed to be touching it.  Please revert those changes.

Heads up that I've landed this change:
https://github.com/sorbet/sorbet/pull/8169
which changes the way that the ./bazel command works so that checking out old and new Sorbet commits will always have the right version of Bazel installed.
(This should make it so that if, after this PR were to land, someone clones the repo fresh, builds Sorbet, then checks out an old commit and attempts to build it, their second build correctly uses the x86_64 version of Bazel, instead of re-using the already-downloaded arm64 version of Bazel.)

Please revert those changes.

@froydnj done, but I'm confused about what you were asking in the first place then?

Heads up that I've landed this change, which will conflict: https://github.com/sorbet/sorbet/pull/8169

Rebased on master and solved the conflicts 👍

Please revert those changes.

@froydnj done, but I'm confused about what you were asking in the first place then?

This line:
https://github.com/sorbet/sorbet/pull/8162/files#diff-503e2940b9cafef5df10484afabe6f20c6f20cd19b313c9f7ce3bf06ee3a2df5L114
shouldn't be using something out of bazel-bin/.


Add script to be able to find missing file for blob

Hi,
I found the way to upload K8S component and add them to the blobs with
export VERSION=1.18.8
make update

this will create entries for K8S compoenent inside the ./config/blobs.yml
but some others component are missing and I don't find any script who downdload and add blod for them
such as :
ipvsadm/ipvsadm-1.30.tar.gz:
ipvsadm/libnl-3.2.25.tar.gz:
ipvsadm/popt-1.16.tar.gz:
jq/jq:
lb/haproxy-1.8.22.tar.gz:
lb/keepalived-2.0.16.tar.gz:
nfs-c7-rpms/gssproxy-0.7.0-26.el7.x86_64.rpm:
nfs-c7-rpms/keyutils-1.5.8-3.el7.x86_64.rpm:
nfs-c7-rpms/libbasicobjects-0.1.1-32.el7.x86_64.rpm:
nfs-c7-rpms/libcollection-0.7.0-32.el7.x86_64.rpm:
nfs-c7-rpms/libevent-2.0.21-4.el7.x86_64.rpm:
nfs-c7-rpms/libini_config-1.3.1-32.el7.x86_64.rpm:
nfs-c7-rpms/libnfsidmap-0.25-19.el7.x86_64.rpm:
nfs-c7-rpms/libpath_utils-0.2.1-32.el7.x86_64.rpm:
nfs-c7-rpms/libref_array-0.1.5-32.el7.x86_64.rpm:
nfs-c7-rpms/libverto-libevent-0.2.5-4.el7.x86_64.rpm:
nfs-c7-rpms/nfs-utils-1.3.0-0.65.el7.x86_64.rpm:
nfs-c7-rpms/quota-4.01-19.el7.x86_64.rpm:
nfs-c7-rpms/rpcbind-0.2.0-48.el7.x86_64.rpm:
nfs-trusty-debs/libevent-2.0-5_2.0.21-stable-1ubuntu<IP_ADDRESS>_amd64.deb:
nfs-trusty-debs/libkeyutils1_1.5.6-1_amd64.deb:
nfs-trusty-debs/libnfsidmap2_0.25-5_amd64.deb:
nfs-trusty-debs/nfs-common_1.2.8-6ubuntu1.2_amd64.deb:
nfs-trusty-debs/nfs-kernel-server_1.2.8-6ubuntu1.2_amd64.deb:
nfs-trusty-debs/rpcbind_0.2.1-2ubuntu2.2_amd64.deb:
nfs-xenial-debs/keyutils_1.5.9-8ubuntu1_amd64.deb:
nfs-xenial-debs/libevent-2.0-5_2.0.21-stable-2ubuntu<IP_ADDRESS>_amd64.deb:
nfs-xenial-debs/libnfsidmap2_0.25-5_amd64.deb:
nfs-xenial-debs/nfs-common_1.2.8-9ubuntu12_amd64.deb:
nfs-xenial-debs/nfs-kernel-server_1.2.8-9ubuntu12_amd64.deb:
nfs-xenial-debs/rpcbind_0.2.3-0.2_amd64.deb:
socat/socat-<IP_ADDRESS>.tar.bz2:

Do you think that we need to add the missing file at the end of utils/update-from-upstream ? of make another file for that?
there is utils/getrpm for nfs-c7-rpms/*  but it doesn't do add blob and nothing for *.deb
nor
socat/socat-<IP_ADDRESS>.tar.bz2
ipvsadm/ipvsadm-1.30.tar.gz
ipvsadm/libnl-3.2.25.tar.gz
ipvsadm/popt-1.16.tar.gz
jq/jq
lb/haproxy-1.8.22.tar.gz
lb/keepalived-2.0.16.tar.gz

What are you trying to accomplish?

On my bosh release, I have a addblob.sh to downlod and add the blob. I think it's a good thing when a bosh release is done to know from where each file is coming. I want to be able to rebuild every thing to test for example a new version or if a CVE is found anywhere. You've also done for some file this but not for all. Is there any reason about that ?

If you're just trying to get the blobs, bosh sync-blobs should download them and populate the local working directory with the tarballs.

I already do that but with this I'm not able to know from where the blog came. by example the socat file came from I don't know and so on I'm not able to check if a new version exist or not.

Okay, so the answer to

What are you trying to accomplish?

is "check for new versions of blobs"
The reason those blobs are not in the update-blobs script is that they change so infrequently, and I only built that script because I got tired of manually chasing down new versions of things.  I have been working on another project that unifies all the messy logic of "what is the latest version of X available", a surprisingly intractable problem that stymies a whole host of release engineering activities.  When I finish that up, I plan to rework the packaging in this BOSH release (if BOSH is still a thing by then) to take advantage of that.


Adding waitOnNewGames and waitTimeOnNewGame to seeding-mode plugin

Waiting for the previus PR to be accepted. (@Thomas-Smyth let me know if I need to close this one since I see the previus PR inside this one too, but perhaps it will dissapear after you accept the previus one dunno tbh)

Fixing https://github.com/Thomas-Smyth/SquadJS/issues/43