Andrew Halberstadt [:ahal] Reporter
	Description • 11 years ago

We have quite a few prefs that require run time information (e.g %(server)s). Interpolating these at run time isn't a problem when the prefs are baked into the harness python code.

In bug 830430 we want to pull the preferences into their own separate files which would cause some problems. The UX of passing in a file path as well as a dictionary of values to interpolate to mozprofile is clunky and confusing. How can we know which values are necessary to interpolate with which prefs files? How can we know which values aren't necessary? Will this lead to this pattern being used more and more in the future? It could get pretty confusing.

I've been thinking about this a bit and the best solution I've come up with so far is for the harnesses to put all run time information that it thinks is important (e.g server path, number of chunks etc..) into mozinfo. Mozprofile would then just always interpolate prefs (and whatever else makes sense) with the mozinfo dict. I think if the harness adds a few basic pieces of information to mozinfo, that would be enough to cover about 98% of prefs.js files. Come to think of it we could just update mozinfo with all the information from the CLI options and that would automatically solve most (if not all) of our production use cases.

	Jeff Hammel
	Comment 1 • 11 years ago

Since we already do this with writemozinfo + mozinfo in the build system, I think this is the natural progression.  I think for (most?) in-tree testing and all of production testing, we will want to work as much as possible with mozinfo processing as much information (so long as its key-value pairs) that we need.

There is a bit of churn in my mind as far as what reads mozinfo. The bug clearly points to mozprofile, though I could make an equally compelling argument for mozrunner.  Currently mozprofile doesn't depend on or use mozinfo, but that's easy fixable.  I don't know if it matters much.  I would probably put it in mozrunner and have that pass as straight interpolation dict to mozprofile, having mozrunner create and pass this as part of profile handling.  But I don't necessarily maintain that this is "correct" per say.  It it doesn't work we can move easily enough later.

	Andrew Halberstadt [:ahal] Reporter
	Comment 2 • 11 years ago

The problem with mozrunner is that I don't think everything will be using that as an entry point. I think some things might want to consume mozprocess directly for finer grained control but still want to do profile management. Other things like running the tests remotely on an emulator or device *can't* use mozrunner as it stands now and need to use mozdevice + mozprofile instead. (We actually have the same problem with environment. It is currently all handled in mozrunner but not everything can use mozrunner.)

I think this ties in to some of the investigation Will is doing and I'm planning to raise it at Tuesday's meeting.

	Jeff Hammel
	Comment 3 • 11 years ago

Sounds like a plan.  Though I do tend to think the more I think about it that it should be up to the consumer to give the interpolation dictionary. I'd be fine with writing a convenience method for mozprofile, though this I propose reluctantly since mozprofile doesnt currently use mozinfo or need it for anything else. %(server)s, in particular is not in mozinfo currently and I'm not sure what would/should know about it below the test harness level.

For environment, a mozenv package has been proposed.  I'm certainly fine (more than fine, even :) in making that a reality and moving that out of mozrunner. There's lots of cleanup to do here...

	Geoff Brown [:gbrown]
	Comment 4 • 6 years ago

Mass closing bugs with no activity in 2+ years. If this bug is important to you, please re-open.