Allow script options to be set at the file level


If I have a project with a large number of scripts in it, I might want to test individual scripts. Currently there is only one location to set the script arguments and/or interpreter arguments - through the project file. This means that if I want to test scripts A and B from the same project independently, I have to modify settings at the project level instead of the file level.

You can already right-click a script and choose "Start with Debugging". It would be nice if you could configure debugging properties at the file level, and "Start with Debugging" on an individual file, as opposed to F5, would use the file's debugging settings.


Zooba wrote Jul 17, 2014 at 9:19 PM

I've thought about this one and the way I'd rather do it is have a launch option/menu command that pops up a dialog with, among other things, a box to enter script arguments (see #1359). This could remember the last value used for that file, which would be almost identical to what you're asking here (except that it probably wouldn't be saved in the project file, and hence would not travel to other machines...).

Does that sound like it would cover your needs?

zturner wrote Jul 17, 2014 at 9:53 PM

I do think it would be an improvement. Saving in the project file would still be nice, though.

I guess I kind of envision something like how Visual Studio handles property inheritance with native code projects. You can edit C++ options for a project, and then at the file level choose to override them or override compilation options for a specific file. So in my ideal scenario, I imagine something where at the project level you can enter whatever command line options you want, and if you do nothing, then F5 will inherit the properties from the project, but if you've overriden them (an identical UI to the Project Debug settings UI would be available for each module), then the file level options would be used.

Admittedly, I personally don't have an immediate need for this kind of flexibility, and your proposed solution would suit my needs, but it seems like generally useful functionality.

zturner wrote Mar 16 at 5:41 PM

Is there any chance of getting this feature in in an upcoming release? Haven't seen any updates for the past 9 months.

Zooba wrote Mar 16 at 8:03 PM

We're regularly reconsidering everything, but this hasn't made it above some of our other priorities yet. Having per-file properties like in C++ would be nice, but we currently don't even support different Debug/Release properties, so it's hard to justify one without the other. At this stage, I don't think 2.2 will get either of them, and whether the subsequent release does will largely depend on how long we can spend on it and what other needs come up. (It would be nice if we had a definite roadmap, but there's basically no chance we'd be able to stick to it anyway :) )

zturner wrote Mar 16 at 8:34 PM

Would you accept a patch that adds this? (Obviously I'm not guaranteeing I'll be able to work on this, but just maybe something I can tinker at in my spare time). If yes, could you name-drop a few areas of interest in the codebase that I should become familiar with to do this?

Zooba wrote Mar 16 at 11:36 PM

Absolutely! (with the usual caveats about quality, tests, etc) In fact, the biggest concern here would be that the behaviour makes sense and doesn't cause more confusion than help.

I'd suggest that you'd be looking at the PythonFileNode class as a place to keep properties in memory and save/load them to the project file (via its ProjectElement member), and StartScriptCommand.cs which contains the two commands for launching a file (rather than a project) - you'll need to be able to find the file node there (which I think it already does, but it doesn't use it for anything) to get the properties and pass them through.

Now I look a little deeper, we'll have to add an IProjectLauncher2 interface that can take all the other options (interpreter path, interpreter arguments, script file, script arguments, working directory, environment variables, debug yes/no) and implement that on our existing launchers. Then we'll probably need an PythonFileNodeProperties class to expose the properties in the Properties pane, as well as whatever other UI we wanted to add around this - I don't think we can easily reuse the VC UI, unfortunately.

As you can see, this very quickly turns into considerably more work than it may seem initially :) I'm not trying to scare you off (though I'll understand if that's the effect), but we can't really get by without doing all of these changes. If you're not scared off, I'm happy to help walk you through doing this.

zturner wrote Mar 17 at 12:03 AM

What about for displaying the UI? I guess a new context menu item would be needed that is enabled for every FileNode similar to the one on the current ProjectNode.

It would look more or less identical to the UI for the ProjectNode, and its initial values would be populated with those from the ProjectNode, but would be overridable (basically an identical to how you can open a Properties window for a file in a C++ project, but change compilation settings on a per-file basis).

Like you said, to cross all the t's and dot all the i's it's probably quite complex. Is it worth trying to add this incrementally but disabled behind some kind of preprocessing directives which are off by default? This would allow the functionality to go in in smaller pieces, but not be turned on until it's finished. And it might allow me to do some of the work, but if I end up getting stuck, allow you or someone else to do a much smaller amount of work to finish it off.

The alternative is I work on it until I think it's basically "done" and then give you a big mega-patch. But this might take an infinite amount of time :)

Zooba wrote Mar 19 at 12:44 AM

If you fork the project then you can freely commit as often as you like, and when you push back up to CodePlex then we can provide feedback and guidance.

A big mega-patch isn't so bad when you've seen it grow

pminaev wrote Mar 21 at 2:20 AM

As a shortcut for UI, note that there is also the Properties window. We currently surface a few project properties for the project node that way (and, really, should probably display all of them); the same could be done for individual file nodes. This can save a lot of time for the initial prototyping, and proper UI can be added later.