The usage of "ptools" seems to break the "build" function of middleman on Windows about middleman-deploy HOT 18 CLOSED

I talked to the author of ptools, and he told me that this behavior in ptools is by design. And it's not ptools who changes this behavior but win32/file.

from middleman-deploy.

If you can tell me what that if-clause is trying to do generally, maybe I can help you with a better solution.

from middleman-deploy.

@djberg96 Thanks for your help! But I haven't started to look into those logics. Instead, I'm looking at what from ptools is used in this gem. Seems only File.binary?().

from middleman-deploy.

I guess I've found the problem...

The final moment before crash in middleman is at middleman-core-3.3.2/lib/middleman-core/cli/build.rb:193:

(@source_dir + @app.images_dir).relative_path_from(@app.root_path)

Here, the @source_dir comes from middleman-core-3.3.2/lib/middleman-core/application.rb:214:

    def source_dir
      File.join(root, config[:source])
    end

which is parsed by File.join.

While the @app.root_path comes from middleman-core-3.3.2/lib/middleman-core/application.rb:59:

    def self.root
      ENV['MM_ROOT'] || Dir.pwd
    end
    delegate :root, :to => :"self.class"

    # Pathname-addressed root
    def self.root_path
      Pathname(root)
    end

which is un-parsed.

Both variables are {Pathname}.

When executed without win32/file, both variables were using /. But when we required win32/file, the @source_dir became with \ while the @app.root_path was still with /. And the #relative_path_from of {Pathname} does not allow comparing paths with different separators.

This is tricky... Because middleman itself does not using win32/file. I don't think that we can say it's a bug of middleman. But at middleman-deploy side, I don't know how to deal with it.

from middleman-deploy.

I tried to override @source_dir or @app.root_path but failed because of this lines:

# middleman-core-3.3.2/lib/middleman-core/cli/build.rb:206
if @build_dir.expand_path.relative_path_from(@source_dir).to_s =~ /\A[.\/]+\Z/

The pathname lib behave differently in different methods after required win32/file.

Some methods like + will convert / to \, but #expand_path always returns path with '/' no matter win32/file is required or not.

More important, Pathname#relative_path_from always crash if the path is with '/' when win32/file is required.

I'll try these possible solutions tomorrow if I have time, but I don't believe any of them will be a good solution, at best a workaround:

1. Remove ptools from ftp.rb & sftp.rb, then find another substitute to provide File#binary?
2. Overrides a part of what win32/file has overrided back.
3. Overrides some methods of ruby's Pathname class.

Is there any expert can help? 😿

from middleman-deploy.

What happens if you install and require the pathname2 gem?

from middleman-deploy.

It crashed because pathname2 let Pathname#join() to return a string instead of a new Pathname.

from middleman-deploy.

There are too many codes in middleman are using plain string to process paths which conflicts win32/file...

# e.g.
base_path = path.sub("#{load_path}/", '')
# or
if load_path.end_with?('/images')

from middleman-deploy.

This is something I wouldn't do:

if load_path.end_with?('/images')

Instead:

if File.basename(load_path) == 'images'

Using String#sub to mangle paths is a bad idea in general. With respect, I think maybe some refactoring is in order.

from middleman-deploy.

Hm, maybe I need to updated the pathname2 gem then. Arguably a bug.

from middleman-deploy.

I updated the pathname2 gem at least so that Pathname#join and Pathname#expand_path now return Pathname objects.

from middleman-deploy.

@djberg96 Tried pathname2 =1.7.2. This time bundler-1.6.2/lib/bundler.rb:192 crashed:

def root
  default_gemfile.dirname.expand_path
end

Cause is Pathname#dirname returns plain string in some case:

require 'pathname'
puts Pathname.new('D:/asdf/qwert').dirname.expand_path
# => D:/asdf
require 'pathname2'
puts Pathname.new('D:/asdf/qwert').dirname.expand_path
# => undefined method `expand_path' for "D:\\asdf":String (NoMethodError)

from middleman-deploy.

Ok, both basename and dirname have been updated to return Pathname objects in 1.7.3.

from middleman-deploy.

Does anything need to happen to middleman deploy so that it picks up these updates?

from middleman-deploy.

I am currently facing the same issue, darn. Did @whitetrefoil solve this somehow eventually? or resolved to use some other gem? Hence, if the problem is all the way inside middleman-core - I believe that we can't get this solved here, or can we?

My setup is: middleman-deploy (0.2.4), middleman (3.3.3) and ptools (1.2.4 universal-mingw32)

from middleman-deploy.

Is this still a problem since I've update pathname2?

from middleman-deploy.

@whitetrefoil Any luck?

from middleman-deploy.

@djberg96 oops... Sorry, I didn't see your previous message. I haven't written ruby for years, and I can't remember details of this issue. I need some time to catch up.

I guess we can close this issue. If there's still problem we can just reopen it.😄

from middleman-deploy.