Skip to content
This repository has been archived by the owner on Apr 20, 2022. It is now read-only.

[draft/inprogress] Metadata changes #21

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

fearthecowboy
Copy link
Member

No description provided.

@fearthecowboy fearthecowboy requested a review from a team as a code owner March 10, 2022 22:49
Copy link
Contributor

@gcampbell-msft gcampbell-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, just a couple of notes and questions

@itodirel itodirel requested a review from BillyONeal March 11, 2022 02:10
@BillyONeal
Copy link
Member

Is this still draft/inprogress?

@fearthecowboy
Copy link
Member Author

Yes. I'll just open a PR in the other repo

@BillyONeal
Copy link
Member

Yes. I'll just open a PR in the other repo

I think it's OK to merge here until the PR over there lands; it's easy to replay over there with git apply.

@fearthecowboy
Copy link
Member Author

Either here or there is fine with me -- I'm solving one last thing and it would be ready.

Copy link
Member

@BillyONeal BillyONeal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with this conditional on a second review on the shell stuff and confirmation of how the catalog is getting updated. We'll talk about transition plan tomorrow.


/** a collection of 'published locations' from artifacts. useful for msbuild */
locations = new Map<string, Uri>();
// add any remaining entries from existing environment
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we warn if this happens? I'm thinking of cases like trying to activate a compiler but doing so from a "developer command prompt" and accidentally getting a horrible mishmash of stuff.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If what happens? There is already an existing variable?

Path, Libpath, Include etc - we're just inserting items into the beginning of the variable.

I dunno what we'd do differently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For PATH we must merge with what happens from the system. But for something like INCLUDE if that's already set the result will probably be a broken mess?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(To be clear, I'm not saying we would do anything different but it may be worth warning about)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth watching to see what happens - My worry would be that with a lot of small embedded libs that want a folder added to libpath, we'd be spewing a lot of warnings that are expected.

Thinking about it, if we're always inserting at the front of paths, I'd think that the stuff at the end shouldn't be problematic unless there was no other matches. But might have an impact on intellisense scanning, etc.

Worth thinking about.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth watching to see what happens - My worry would be that with a lot of small embedded libs that want a folder added to libpath, we'd be spewing a lot of warnings that are expected.

Thinking about it, if we're always inserting at the front of paths, I'd think that the stuff at the end shouldn't be problematic unless there was no other matches. But might have an impact on intellisense scanning, etc.

Worth thinking about.

strict.equal(doc.settings.tools.get('CC'), 'foo/bar/cl.exe', 'should have a value');
strict.equal(doc.settings.tools.get('CXX'), 'bin/baz/cl.exe', 'should have a value');
strict.equal(doc.settings.tools.get('Whatever'), 'some/tool/path/foo', 'should have a value');
strict.equal(doc.exports.tools.get('CC'), 'foo/bar/cl.exe', 'should have a value');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a schema change, right? Is anyone on the hook to change the default catalog?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I have an updated copy of the repo locally (and was going to convert it to all JSON).

import { Uri } from '../util/uri';
import { toXml } from '../util/xml';
import { Artifact } from './artifact';


function generateCmdScript(variables: Dictionary<string>, aliases: Dictionary<string>): string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked for a second opinion on what this is doing with other vcpkg maintainers who have more bash experience.

Copy link
Member

@vicroms vicroms Mar 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these (generateXYZ) look good to me, but I'm probably the least experienced with bash :P

function generatePosixScript(variables: Dictionary<string>, aliases: Dictionary<string>): string {
return linq.entries(variables).select(([k, v]) => { return v ? `export ${k}="${v}"` : `unset ${k[0]}`; }).join('\n') +
'\n' +
linq.entries(aliases).select(([k, v]) => { return v ? `${k}() {\n ${v} $* \n}` : `unset -f ${v} > /dev/null 2>&1`; }).join('\n') +

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason this uses functions instead of alias?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, not that I can think of. I did it right after powershell, where they did need to be functions. Did you want it to use alias/unalias instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind these being functions, they are more flexible and accept positional parameters if we ever were to need those.

@fearthecowboy
Copy link
Member Author

I merged my other branch into this one, both need updates in the registry, and it's easier to keep one branch of that.

@@ -209,43 +204,71 @@ export class Artifact extends ArtifactBase {
await this.targetLocation.delete({ recursive: true, useTrash: false });
}

matchFilesInArtifact(glob: string) {
const results = match(this.allPaths, glob.trim(), { dot: true, cwd: this.targetLocation.fsPath, unescape: true });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const results = match(this.allPaths, glob.trim(), { dot: true, cwd: this.targetLocation.fsPath, unescape: true });
const results = match(this.allPaths, glob, { dot: true, cwd: this.targetLocation.fsPath, unescape: true });

Do we really need this trim? If we do that sounds like a bug.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if someone has spaces around the glob in the artifact, "{ **/*.h }" then you get spaces around the string.

return sandbox[response];
};
}
export function safeEval(code: string, context?: any): any {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I missed this before but I am strongly opposed to allowing arbitrary ecmascript (a la eval()) in artifact metadata because this forces any implementation of this stuff to include an entire ecmascript implementation going forward. (I know we have no immediate plans to implement with anything else but other customers like Intellisense may want to have higher level understanding of this, and we may be called upon to create ports of this in the future for CPUs where a version of Node does not exist because we are proposing this to underpin all builds)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a validator that reduces that to supporting only comparisons - <value> <comparator> <value> where value is an acceptable literal value or $variable reference. Very small surface area. I will add it tomorrow morning.

@BillyONeal
Copy link
Member

The merger PR microsoft/vcpkg-tool#428 has landed, can you replay this over there?

@fearthecowboy
Copy link
Member Author

Had to refactor a bit more, and we're still testing, but I'll send this over to the other repo as soon as it's ready.

import { cmdlineToArray, execute } from '../util/exec-cmd';
import { createSandbox } from '../util/safeEval';
import { safeEval, valiadateExpression } from '../util/safeEval';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
import { safeEval, valiadateExpression } from '../util/safeEval';
import { safeEval, validateExpression } from '../util/safeEval';

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants