Add windows support about php-scoper HOT 15 CLOSED

I think this can be closed for inactivity as well, ref #123

Since there are no active Windows user around, there's nothing to be done about this now

from php-scoper.

Thanks for looking into it :)

Alternatively, this could possibly be fixed by allowing the output-dir to be set in the config file which would allow users to use DIR and the likes to create absolute paths themselves.

I'm fine with that solution, provided (and after a cursory look that shouldn't be an issue) the change stays in AddPrefixCommand and does not affect the rest of the application API.

from php-scoper.

I'll have a proper look when I have more time. For now, I've used a horrible work-around (copy/paste dir + bits from the autoload file from a linux user) to at least get the project I need it for in a running state, but as you can imagine, that's not a sustainable solution.

from php-scoper.

Some windows incompatibilities may have sneaked in as:

• the AppVeyor build is failing, not because of the tests but the setup, and I didn't have time to investigate it
• I don't use Windows

Would it be possible for you to investigate where this happens?

from php-scoper.

Debug says:

 () at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\filesystem\Filesystem.php:103
 Symfony\Component\Filesystem\Filesystem->mkdir() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\filesystem\Filesystem.php:673
 Symfony\Component\Filesystem\Filesystem->dumpFile() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\humbug\php-scoper\src\Handler\HandleAddPrefix.php:275
 Humbug\PhpScoper\Handler\HandleAddPrefix->scopeFile() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\humbug\php-scoper\src\Handler\HandleAddPrefix.php:219
 Humbug\PhpScoper\Handler\HandleAddPrefix->scopeFiles() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\humbug\php-scoper\src\Handler\HandleAddPrefix.php:72
 Humbug\PhpScoper\Handler\HandleAddPrefix->__invoke() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\humbug\php-scoper\src\Console\Command\AddPrefixCommand.php:163
 Humbug\PhpScoper\Console\Command\AddPrefixCommand->execute() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\console\Command\Command.php:262
 Symfony\Component\Console\Command\Command->run() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\console\Application.php:888
 Symfony\Component\Console\Application->doRunCommand() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\console\Application.php:224
 Symfony\Component\Console\Application->doRun() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\symfony\console\Application.php:125
 Symfony\Component\Console\Application->run() at C:\Users\Kuba\AppData\Roaming\Composer\vendor\humbug\php-scoper\bin\php-scoper:37

from php-scoper.

So it's probably coming from here: it's the function where we collect all the files to scope and calculate the output path

from php-scoper.

Thanks for the hint. It's actually a get_common_path() function problem.

Instead getting:
C:\www\test\public\wp-content\plugins\asdasdasdsad

I have:
\:\www\test\public\wp-content\plugins\asdasdasdsad

I'm trying to fix this

from php-scoper.

I don't mind leaving the issue open just for visibility, at least if someone opens the issue tab one can see what is left. Since there is only a handful of issues it's fine :)

from php-scoper.

Sure, it just makes priorities less clear from issuses overview.

from php-scoper.

The most important issues are putted on the 1.0.0 milestones, the others can be dealt with later. Granted that milestones might not grant as much visibility as we might want though

from php-scoper.

I learned to ignore milestones on issues/PRs, since they're often obsolete and unmaintained. E.g. milestone 1.0.0 on issues, when version 3.2 was released.

I prefer "What you see is what you get." :)

from php-scoper.

Still does not work under Windows. Same bug with paths.

In Filesystem.php line 67:
Failed to create "C:\tmp\sss\buildC:\tmp\sss....

from php-scoper.

I can confirm this still looks to be an issue on Windows. Running into it as well.

from php-scoper.

Apologize @tivnet and @jrfnl but I'll have to agree with @TomasVotruba comment on this one.

I'm all up for adding Windows support, but since I don't have much time, don't have Windows and not peculiarly familiar with AppVeyor either, I will not go to great length for it. In other words, if a Windows support will be added, it will be through community support not by me.

If you are willing to help out on the issue, the best thing to do is to try it locally and make it work to provide a PR fixing the issues. To add a better support, I think the best way to go would be to enable AppVeyor on a fork to try to set it up, I could then enable AppVeyor on this repository to ensure the future changes will also work on Windows.

from php-scoper.

@theofidry Understood. It's been on my long-term "investigate" list for a few months now. Will try and have a look when I find the time.

I'm inclined to think it should be a relatively easy fix, something along the lines of checking whether output-dir has been passed from the command-line, if so, check if it's a relative path and turn it into an absolute path (and make sure the default is an absolute path as well).

Alternatively, this could possibly be fixed by allowing the output-dir to be set in the config file which would allow users to use __DIR__ and the likes to create absolute paths themselves.

from php-scoper.