Backport #1975: Backport Dir.mktmpdir

• Status: Closed
• Assignee: wyhaines (Kirk Haines)

[wyhaines (Kirk Haines)]

=begin
Dir.mktmpdir exists in 1.8 HEAD and 1.8.7, and is used in the test suite for Backport #1168, so it needs to be backported to 1.8.6 to facilitate use of the existing test suite.
=end

[wyhaines (Kirk Haines)]

=begin
On Fri, Aug 21, 2009 at 8:17 PM, Tanaka [e-mail] wrote:

In article [e-mail],
 Kirk Haines [e-mail] writes:

Dir.mktmpdir exists in 1.8 HEAD and 1.8.7, and is used in the test suite for Backport #1168, so it needs to be backported to 1.8.6 to facilitate use of the existing test suite.

It is possible to copy Dir.mktmpdir to the test suite.

When I needed Dir.mktmpdir for bootstraptest/runner.rb in
1.9 which may be run by 1.8.6, I copied it.

(nod) It has been backported through the rest of the 1.8 line,
though, and only adds capability; it doesn't change any existing
functionality, so I don't see a problem with just backporting it to
1.8.6. If I am incorrect in that analysis, please let me know.

Thank you,

Kirk Haines

=end

[shyouhei (Shyouhei Urabe)]

=begin
Tanaka Akira wrote:

It seems your maintainance policy is different from Urabe's.
Urabe's policy is "bugfix only". No new feature.

Just wanted to mention that I respect Kirk's decision on 1.8.6. I don't stop
him to add new features if he needed to.

A consensus over that would be desired though.

Attachment: signature.asc
=end

[matz (Yukihiro Matsumoto)]

=begin
Hi,

In message "Re: [ruby-core:25096] Re: [Backport #1975] Backport Dir.mktmpdir"
on Tue, 25 Aug 2009 01:44:15 +0900, Urabe Shyouhei [e-mail] writes:

|Just wanted to mention that I respect Kirk's decision on 1.8.6. I don't stop
|him to add new features if he needed to.

I am not going to allow him to add any new feature to 1.8.6 without
adding the same feature to the trunk and newer versions, which
requires consensus with maintainers of those versions. This is a
basic principle.

						matz.

=end

[wyhaines (Kirk Haines)]

=begin
On Mon, Aug 24, 2009 at 10:27 AM, Tanaka [e-mail] wrote:

In article [e-mail],
 Kirk Haines [e-mail] writes:

(nod)  It has been backported through the rest of the 1.8 line,
though, and only adds capability; it doesn't change any existing
functionality, so I don't see a problem with just backporting it to
1.8.6.  If I am incorrect in that analysis, please let me know.

It seems your maintainance policy is different from Urabe's.
Urabe's policy is "bugfix only".  No new feature.

Although policy difference doesn't mean bad in general, I
guess the difference makes the distinction between 1.8.6 and
1.8.7 bit unclear.

That distinction is somewhat blurry, though. Some of the bugfixes
have introduced implicit behavioral changes, and IMHO, that is OK so
long as the behavioral change is required to fix the bug, or is more
correct (as in some of the recent fixes with handling of Bignums,
infinity, etc....). In general, I'm not adopting new features from
1.8.7, but where there is something that won't break existing code
that depends on 1.8.6, and where there's an arguable benefit to
backporting something that has already percholated through 1.8 HEAD
and 1.8.7, I don't see harm in allowing that capability to fall
through to 1.8.6. There are a lot of changes that can't easily move
from 1.8.7 to 1.8.6 because of larger, fundamental changes to the
code. In the case of Dir.mktmpdir, which is just a pure ruby addition
to a class, and doesn't have a larger API that goes with it, I don't
see a problem, especially since it, in turn, simplifies the test case
code in at least two instances.

Contrast this with String#start_with?. That is also being used by the
test_file_exhaustive.rb test set, but I won't consider backporting it
because it is a far larger change that lives in the context of a
number of other String class changes which are unlikely to be truly
backwards compatible with existing 1.8.6 behavior. 1.8.6 should not
mirror 1.8.7, because, IMHO, the progression in the 1.8 and 1.9 lines
should encourage people to eventually move to those versions because
of the advancements to be found there, but there are still a large
number of people entrenched in 1.8.6, so modest refinements which can
be backported without risk of breaking someone's code, and which offer
some other tangible advantage, should be considered.

I am completely open to discussion regarding my perspective, though.
If anyone thinks I should have a different policy, please speak up and
tell me why.

Thanks,

Kirk Haines

=end

[shyouhei (Shyouhei Urabe)]

=begin
Yukihiro Matsumoto wrote:

|Just wanted to mention that I respect Kirk's decision on 1.8.6. I don't stop
|him to add new features if he needed to.

I am not going to allow him to add any new feature to 1.8.6 without
adding the same feature to the trunk and newer versions, which
requires consensus with maintainers of those versions. This is a
basic principle.

In this case, Dir.mktmpdir does exist on all other live branches than 1.8.6.
It's totally Kirk's business whether or not to backport it.

zsh % for ruby in ~/target/*/bin/ruby; do
zsh > $ruby -rtmpdir -ve '
zsh > p Dir.methods.map {|i|
zsh > i.to_s
zsh > }.sort.include?("mktmpdir")
zsh > '
zsh > done
ruby 1.8.5 (2008-06-20 patchlevel 231) [x86_64-linux]
false
ruby 1.8.6 (2009-08-21 patchlevel 386) [x86_64-linux]
false
ruby 1.8.7 (2009-08-09 patchlevel 196) [x86_64-linux]
true
ruby 1.8.8dev (2009-08-24 revision 24641) [x86_64-linux]
true
ruby 1.9.1p281 (2009-08-09 revision 24476) [x86_64-linux]
true
ruby 1.9.2dev (2009-08-25 trunk 24642) [x86_64-linux]
true

=end

[shyouhei (Shyouhei Urabe)]

=begin
Kirk Haines wrote:

That distinction is somewhat blurry, though. Some of the bugfixes
have introduced implicit behavioral changes, and IMHO, that is OK so
long as the behavioral change is required to fix the bug, or is more
correct (as in some of the recent fixes with handling of Bignums,
infinity, etc....).

I strongly agree with this. I wrote it before but "to fix a bug is to change
something". Bugfixes and behavioral changes are sometimes distinguishable, but
not always. On really delicate situations, I don't know a way to say which.
That's one of a reason for me to believe Kirk on his decision; I may not have
other tactics than that.

In general, I'm not adopting new features from
1.8.7, but where there is something that won't break existing code
that depends on 1.8.6, and where there's an arguable benefit to
backporting something that has already percholated through 1.8 HEAD
and 1.8.7, I don't see harm in allowing that capability to fall
through to 1.8.6. There are a lot of changes that can't easily move
from 1.8.7 to 1.8.6 because of larger, fundamental changes to the
code. In the case of Dir.mktmpdir, which is just a pure ruby addition
to a class, and doesn't have a larger API that goes with it, I don't
see a problem, especially since it, in turn, simplifies the test case
code in at least two instances.

It's my preference when I was the 1.8.6 mentor, but if a change itself isn't
a bugfix, I might leave it unapplied. That's the policy Tanaka-san stated as
"No new feature". I analyzed myself and now I think it's because I think
people should move to a newer ruby in a long term. More radically speaking, I
believe no new scripts should be written targeted to 1.8.6. 1.8.6 is for those
scripts that has already been written for it. From that point, non-bugfix
changes aren't welcomed because I want to encourage people NOT to write a
script for 1.8.6.

Contrast this with String#start_with?. That is also being used by the
test_file_exhaustive.rb test set, but I won't consider backporting it
because it is a far larger change that lives in the context of a
number of other String class changes which are unlikely to be truly
backwards compatible with existing 1.8.6 behavior. 1.8.6 should not
mirror 1.8.7, because, IMHO, the progression in the 1.8 and 1.9 lines
should encourage people to eventually move to those versions because
of the advancements to be found there, but there are still a large
number of people entrenched in 1.8.6, so modest refinements which can
be backported without risk of breaking someone's code, and which offer
some other tangible advantage, should be considered.

So policy differences between you and me is due to our difference in standing
points. I want to make this world as ideal as I dream, while you have more
realistic point of view that this world is not as ideal as I dream. People are
still living on top of 1.8.6. It's true. And we decided to let you manage
1.8.6. The policy difference is easy to accept once I know this point.

I am completely open to discussion regarding my perspective, though.
If anyone thinks I should have a different policy, please speak up and
tell me why.

I don't think you should have one. What I wrote in this mail is I have a
different one. Follow the path you believe.

Attachment: signature.asc
=end

[wyhaines (Kirk Haines)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

=begin
Applied in changeset r24653.
=end

On Friday, August 21, 2009 7:17:28 PM UTC-7, Tanaka Akira wrote:

In article [e-mail],
Kirk Haines [e-mail] writes:

Dir.mktmpdir exists in 1.8 HEAD and 1.8.7, and is used in the test suite
for Backport #1168, so it needs to be backported to 1.8.6 to facilitate use
of the existing test suite.

It is possible to copy Dir.mktmpdir to the test suite.

When I needed Dir.mktmpdir for bootstraptest/runner.rb in
1.9 which may be run by 1.8.6, I copied it.

Tanaka Akira

Sorry for reviving such a long dead thread, but it is the only thing that
I've been able to find that seems remotely related. I'm working on a
project that is using Dir.mktmpdir. I'd like to maintain some backward
compatibility with 1.8.6 and to that end was thinking of adding something
simple like:

unless Dir.respond_to?(:mktmpdir)
def Dir.mktmpdir(prefix_suffix=nil, tmpdir=nil)
case prefix_suffix
when nil
prefix = "d"
suffix = ""
when String
prefix = prefix_suffix
suffix = ""
when Array
prefix = prefix_suffix[0]
suffix = prefix_suffix[1]
else
raise ArgumentError, "unexpected prefix_suffix:
#{prefix_suffix.inspect}"
end
tmpdir ||= Dir.tmpdir
t = Time.now.strftime("%Y%m%d")
n = nil
begin
path = "#{tmpdir}/#{prefix}#{t}-#{$$}-#{rand(0x100000000).to_s(36)}"
path << "-#{n}" if n
path << suffix
Dir.mkdir(path, 0700)
rescue Errno::EEXIST
n ||= 0
n += 1
retry
end

 if block_given?
   begin
     yield path
   ensure
     FileUtils.remove_entry_secure path
   end
 else
   path
 end

end
end

Just a copy-paste from tmpdir.rb from the lib of a 1.8.7 installation
wrapped in a respond_to? into one of my project's files. What I want to
know is how to properly attribute the code in our project from the 1.8.7
lib? There is no statement in the file, and I can find nothing in the
installation or several searches with google.

Can't reuse this code unless I can acknowledge where it comes from, please
let me know how to to this correctly.

Thanks,

Joe