Feature #13197: Gemify fileutils

• Status: Assigned
• Priority: Normal
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: 2.5

[hsbt (Hiroshi SHIBATA)]

This issue is tracking for gem release of FileUtils module.

[hsbt (Hiroshi SHIBATA)]

• Subject changed from Gemfile fileutils to Gemify fileutils

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Closed

Applied in changeset r57550.

---

Added initial gemspec for FileUtils module.

[Feature #13197]

[hsbt (Hiroshi SHIBATA)]

• Status changed from Closed to Assigned

[hsbt (Hiroshi SHIBATA)]

Note: Pathname class depends FileUtils. If we added breaking changes to FileUtils, Pathname is also broken.

https://github.com/ruby/ruby/blob/trunk/ext/pathname/lib/pathname.rb#L569

So, We need to add dependency FileUtils to Pathname after gem releases of pathname and fileutils.

Example case:

1. pathname-1.0.0 and fileutils-1.0.0 woks fine when Ruby 2.5.0 release.
2. fileutils changes some of public API in Ruby 2.6.0. We will fix pathname class.
3. We need to ship fileutils-2.0.0 and pathname-2.0.0.
4. In this case, pathname-1.0.0 is broken with fileutils-2.0.0.

We need to add dependency of 'fileutils', '~> 1.0.0' to pathname-1.0.0 when Ruby 2.4.0 release.

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #5481: Gemifying Ruby standard library added

[hsbt (Hiroshi SHIBATA)]

fileutils gem is already registered.

• https://rubygems.org/gems/fileutils (It's masked yet)

I ask about this namespace to rubygems.org admin.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Assigned to Closed

I released fileutils-0.7.1 and yanked old versions.

https://rubygems.org/gems/fileutils

[stomar (Marcus Stollsteimer)]

@hsbt, I noticed that the rubygems page has wrong metadata ("Source Code" URL), presumably from the previous gem. This might also be the case for other gems with yanked (unrelated) older gem; I did not check.

And another thought: should homepage in the gemspec be set to ruby-lang.org, or rather to the source code repository (which would be more useful regarding information on issues, releases, ...)?

[hsbt (Hiroshi SHIBATA)]

• Status changed from Closed to Assigned

@stomar

Thanks. source-code still point old metadata. And homepage is the wrong parameter.
I will update it before Ruby 2.5.0preview1.

which would be more useful regarding information on issues, releases, ...

bug.ruby-lang.org and github.com/ruby/fileutils are ok.

[vo.x (Vit Ondruch)]

Maybe somebody should propose "Gem::Specification#source_code" field to RubyGems guys. I don't understand why the "Source Code" field must be set manually on rubygems.org while it would not harm to have it in gem metadata ...

[stomar (Marcus Stollsteimer)]

hsbt (Hiroshi SHIBATA) wrote:

bug.ruby-lang.org and github.com/ruby/fileutils are ok.

This is currently completely unclear to me: what is supposed to be the canonical, "upstream" repository for all those gems, i.e. where should bug tracking and development happen: in Ruby trunk / Redmine, or on GitHub? Is code synced both ways?

(E.g. I recently fixed a GH/ruby/ruby issue for date_core.c in svn; should I have fixed in ruby/date? When, how, by whom are the repos synced?)

I couldn't find helpful information about that in the Wiki or in the respective tickets (e.g. #5481).

[hsbt (Hiroshi SHIBATA)]

what is supposed to be the canonical, "upstream" repository for all those gems

Short answer: upstream is svn.ruby-lang.org.

But some default gems use github for the canonical repository.
Gemification status is still work in progress until Ruby 2.5.0 release.
I'm going to file your concerns to document under the doc directory on ruby source.