On 2013-01-09 20:19, Dustin J. Mitchell wrote:
On Fri, Aug 30, 2013 at 9:24 AM, Henrik Lindberg
<[email protected]> wrote:
Yes, that makes sense. What I am asking is if we also want to be able to
tell if code makes use of features that are newer than what the user would
*like* to use. (My code has to work in both puppet 4 and puppet 3, I am
marking my module as requiring 3, now please tell me if I am using any
features from 4).
I don't think this is particularly useful from the language itself.
If you're operating in a heterogenous environment, then use CI to
ensure this.
How would you ensure this? The fact that it seems to work? Do you have
perfect test coverage? (The parser checks all code paths, not just the
ones that are executed in tests).
As I did in the thread on lazy/eager parsing, I look to Python for
guidance here.
Within a major version, new language features are enabled on a
per-file basis, with 'from __future__ import xxx' where xxx is the
name of the feature you want, e.g., 'with_statement' or
'absolute_import'. This statement enables the new feature for one
minor revision, and becomes a no-op (the feature is always enabled) in
the next. So 'with_statement' was optional in Python-2.5 and
mandatory in 2.6. This is a mechanism for dealing with language
changes that might make previously-valid code invalid. In the case of
'with_statement', code that uses "with" as a variable name will fail
to parse because "with" becomes a language keyword. The process of
upgrading code, including using the cool new feature, looks like this:
(code runs on Python <= 2.5)
1. Upgrade all users to Python == 2.5
2. Remove use of "with" as a variable name
(code runs on all Python versions)
3. Add 'from __future__ import with_statement' and use the cool new
"with" statements
(code runs on Python >= 2.5)
4. Upgrade all users to Python == 2.6
5. Remove now-redundant 'from __future__ import with_statement'
(code runs on Python >= 2.6)
Between major versions (2.x -> 3.x), neither forward- nor
backward-compatibility is expected. Where possible, the devs have
used "from __future__" to ease users' burden, and there's also a
"2to3" tool to convert code from one version to another, but a large
body of code is pretty much doomed to *either* run on 2.x or 3.x.
Given how difficult this transition has been for Puppet, Perl, and
Ruby, let's try to never do this!
I think that the "parser" config parameter in Puppet is similar to the
'from __future__' model, although it doesn't allow selection of
particular features, and it applies processwide, rather than on a
per-file basis. Both of those limitations are fine with me. The
upgrade process to begin using features in the 8.0 parser, while
Puppet-7.3 is the latest version, would be:
(code runs on Puppet <= 7.3)
1. Upgrade all users to Puppet == 7.3
2. Remove all use of language features deprecated in Puppet-7.0
(code runs on all puppet versions)
3. Enable --parser=future, and use cool new features
(code runs on Puppet >= 7.3)
4. Upgrade users to Puppet == 8.0 with --parser=current
(code runs on Puppet >= 8.0)
Note that this way, step 4 doesn't introduce any new language
incompatibilities. Basically, this decouples upgrading Puppet (the
language, which can bring coding headaches) from upgrading puppet (the
system, which brings its own set of operational headaches).
As to naming the revisions, I think "future" and "current" aren't very
good names, and I don't think that versioning the language separately
is a good idea. I also expect that any backward-incompatible changes
to the language will increment Puppet's major revision number. So I
would suggest naming the language revisions after the puppet major
revisions, with the default being the current. So as of Puppet-7.3, I
can write --parser=v7 (the default) or --parser=v8.
Maybe, although there is no definition of what "v8" is. That is only
known when v8 is released. I.e. the "v8" seen in 9x, is not the same as
the v8 seen in 7x. (I think it is better to have a symbolic version for
"future/experimental", and the "default/current".
What we end up picking depends if there is any demand for the "validate
older versions"-feature or not.
We could also offer multiple version support per module, but the runtime
would be at its pre-defined version (everything compiles to the same
catalog), we could however offer migration aid by allowing a module to
stay on an older version (thus missing features, but would also not be
in violation if, say, new keywords are introduced.
Hard to say what is most helpful and least confusing. While it may be
helpful to be smarter it may also give too many knobs to turn.
I am on the fence on this and like to hear what people think.
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
