develooper Front page | perl.perl5.porters | Postings from March 2017

[RFC] We need prose for perl526delta about "." in @INC removal

Thread Next
Kent Fredric
March 28, 2017 15:21
[RFC] We need prose for perl526delta about "." in @INC removal
Message ID:
Given the scope of this problem, I think its important we have this
very thoroughly documented, because the ways this can manifest and
cause problems is I think, unprecedented in scale.

We need to consider 4 audiences:

1. End users.

2. Downstream Maintainers.

3. CPAN Authors.

4. Non-CPAN Authors using Perl as part of their build chains. (eg:
make, automake, autoconf, po4a )

End Users:

Who we can't expect to know much about the code at all, and can't
expect them to even fire open an editor. ( They may be capable, but we
should not expect it )

Downstream Maintainers:

Can be expected to be able to change code, but we can't expect them to
be capable of understanding it, for instance.

For example, their knowledge of Perl may be so rudimentary they may
not understand quote operators or how 'use lib' works.

We also want to document the best way for downstream maintainers to
fix the code they need to fix so that it doesn't create additional
problems later, ( for instance, we shouldn't encourage them to set
PERL_USE_UNSAFE_INC=1 and call it a day )

CPAN Authors:

Will need to be aware of their code being broken in the future ( or in
many cases, immediately ), and will need to be aware of their
downstreams 1 & 2, especially as the workarounds where
PERL_USE_UNSAFE_INC=1 is used are presently scheduled to have a
limited life, and they should endeavour to fix their code A.S.A.P, and
we should be documenting the best way to fix exisiting code for the

Non-CPAN Authors:

This is a hard audience I myself keep forgetting exists, because it
usually falls under the umbrella of "darkpan" because its "not on
CPAN", but its truely a "Greypan", or maybe even a "offwhite-pan"
because they're public opensource utilities that everyone has, and are
just as used ( if not more so ) than Perl itself, but don't end up in
our cross-hairs because they're not part of our toolchain.

They're a weird mix usually somewhere between "Downstream maintainers"
and "CPAN Authors", being familiar with their code and having
established ideas, but are not necessarily "in the loop" or fully
understanding Perl.  They, like CPAN Authors and Maintainers, would be
greatly helped by having clear documentation stating how best to
remedy their problems, and how best to help their affected user base
on older versions with newer perls.

We should also keep in mind that whatever documentation we use to
direct them, we will be inadvertently committing ourselves to support.

A detailed coverage of the "why" and the history of this problem
*could* be useful but it should be a later note, as not to confuse
people who are just doing a speed-run to get their system working

We should also put much more effort into focusing on the problem with
'do', because between it and 'require', do was the most subversive and
was barely noticed, and its nature where it silently gobbles errors
leads it into creating lots of confusion.

Especially as the "do" case likes to hide itself in .pm files, leading
to a false-sense of security of you run your test suites with "." in
@INC which then become silently broken at install-time.

Hence, in order to *not* make this problem worse, we should be trying
to encourage authors to use syntax in their tests to load library
paths that will *continue* to expose defects with using 'do' in
runtime code, as a naive "use lib q[.]" in the tests will make the
bugs in the tests go away, but also hide the runtime bugs which are
still lurking.

I haven't yet written anything myself that would be useful, but we
should get a clear idea of what we're going to write first. ( And this
basic rundown is how I'd proceed to write anything )

Get your brushes out ;)



Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About