Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various issues - version discrepancy & installation question #20

Closed
nathan-io opened this issue Aug 18, 2020 · 13 comments
Closed

Various issues - version discrepancy & installation question #20

nathan-io opened this issue Aug 18, 2020 · 13 comments

Comments

@nathan-io
Copy link

nathan-io commented Aug 18, 2020

Hi, thank you for your this incredibly helpful package!

Hoping you can help with these questions/issues.

Installation

I wanted to confirm that the proper installation method is:

composer global require valeryan/valet-wsl

I ask because the guide I originally followed to install this said to manually add a repository to the global composer.json (pointing to the dev-master branch) and then run composer global update. Perhaps that is outdated.


Version Discrepancy

I have this installed on two machines, both Windows 10 + WSL1.

On one of the machines, valet --version returns "Valet v3.0.0", while on the other it returns "Valet v1.0.6"

This happens regardless of how I install Valet.

I was actually going to submit an issue to laravel/valet (www subdomains don't work), but couldn't figure out the actual version number I have on this machine due to this issue. I see that 1.0.6 is the latest release of this package.


fix and diagnose commands are not defined

I tried to run valet fix and valet diagnose, but neither command is defined. (Same result on both machines.)

@valeryan
Copy link
Owner

Follow: https://github.com/valeryan/valet-wsl/wiki/Installation-Guide

This version does not have any direct association with the main laravel/valet beyond being a fork of a fork. This version just makes a few tweaks to configuration to make it not break under wsl.

It sounds like you have a very outdated version from my alpha experiment branch that was used for testing these fixes. I would delete that version and remove it from your composer file. Then start over using the guide above. Also, note that if you consider upgrading to WSL2 be aware that it's currently not supported. See #7 for details.

@nathan-io
Copy link
Author

Thanks for the quick response!

I would delete that version and remove it from your composer file. Then start over using the guide above.

That's actually what I did before posting this issue. I removed ~/.composer/vendor/valeryan, as well as my global composer.lock. I then edited my global composer.json to remove all reference to the package,

I then ran composer global require valeryan/valet-wsl, and it installed the same version of the package. 1.6 is the latest release of this package, it looks like it's current with master?

The guide that I was originally following said to add the following to global composer.json:

{
  "require": {
    "valeryan/valet-wsl": "dev-master"
  },
  "repositories": [
    {
      "type": "vcs",
      "url": "git@github.com:valeryan/valet-wsl.git"
    }
  ]
}

But the 1.0.6 release is current with master branch, so there's really no difference between this and a simple composer global require valeryan/valet-wsl in terms of what would be downloaded.

On my other machine, where I get "v3.0.0", I was using this old method to install the package - yet I get a different version number there. But again, neither the fix or diagnose commands are recognized on either machine.

Can you confirm that on a fresh WSL instance, composer global require valeryan/valet-wsl doesn't exhibit the behavior for you?


I'm on WSL1, don't plan to upgrade at this time due to the networking issues.

@valeryan
Copy link
Owner

This version of valet does not implement a fix or diagnosis command. Not sure where those commands are coming from.

As for your routing problem. Routing is handle by an external dependency on the Windows side called acrylic dns proxy. Valet sets up the URL for a site based on the folder name by default. It does not setup wildcard routes for the folder I am pretty sure. You can edit the nginx configs that valet creates to support the www yourself pretty easily.

@nathan-io
Copy link
Author

nathan-io commented Aug 19, 2020

This version of valet does not implement a fix or diagnosis command. Not sure where those commands are coming from.

Well, your very own issue template asks if you have run valet fix.

valet diagnosis is mentioned in laravel/valet's issue template.

Perhaps these are from older versions, but I have no idea what version of laravel/valet I'm actually running.

As for your routing problem. Routing is handle by an external dependency on the Windows side called acrylic dns proxy.

I understand how the routing works, and how to edit Nginx config files.

The routing issue I described is specific only to www - everything else works fine, and the same project/site works with any other hostname. This is not about wildcards.

I'm not sure if it's an issue with laravel/valet, or valet-linux, or something with this package. I was originally going to post the issue to laravel/valet, but they won't even look at issues for Valet < 2.0.

Hence, me coming here to sort out the discrepancy with valet --version and gain clarity on how to properly install this.

Could you please confirm that on a fresh WSL instance, composer global require valeryan/valet-wsl doesn't result in the same version result I'm getting? I really think there's a chance this isn't working as intended.

@valeryan
Copy link
Owner

Actually it's not my template it's from the project that I fork from but I will look at it and see where those commands come from and if they should exist somewhere.

@nathan-io
Copy link
Author

Thank you.

Do you have any interest in the valet --version discrepancy? That's ultimately the reason I opened this issue.

@valeryan
Copy link
Owner

You probably have a cached version of the initial alpha release on the one system. I would delete your global vendor folder and do a composer update with the no cache option and see if you get the correct version after deleting the old composer entries for the outdated tutorial and require the package like in the new tutorial. I use the wiki to keep install procedures updated and it is the best place to get the correct information.

@valeryan
Copy link
Owner

@nathan-io did you get your version mismatch sorted?

@nathan-io
Copy link
Author

I had already done what you suggested before even creating this issue, but I just tried again.

nathan@workstation:~/.composer$ nano composer.json # manually removed existing line requiring valeryan/valet-wsl ^1.0
nathan@workstation:~/.composer$ rm composer.lock
nathan@workstation:~/.composer$ composer clearcache
nathan@workstation:~/.composer$ rm -rf cache && rm -rf vendor # just to be doubly sure
nathan@workstation:~/.composer$ composer global require valeryan/valet-wsl

Output of the last command:

Changed current directory to /home/nathan/.composer
Using version ^1.0 for valeryan/valet-wsl
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 9 installs, 0 updates, 0 removals
  - Installing symfony/var-dumper (v5.1.3): Downloading (100%)
  - Installing tightenco/collect (v7.25.0): Downloading (100%)
  - Installing nategood/httpful (0.3.2): Downloading (100%)
  - Installing php-di/invoker (2.1.0): Downloading (100%)
  - Installing mnapoli/silly (1.7.2): Downloading (100%)
  - Installing psr/simple-cache (1.0.1): Downloading (100%)
  - Installing illuminate/contracts (v7.26.1): Downloading (100%)
  - Installing illuminate/container (v7.26.1): Downloading (100%)
  - Installing valeryan/valet-wsl (v1.0.6): Downloading (100%)
Writing lock file
Generating autoload files
12 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Then:

nathan@workstation:~/.composer$ valet --version
Valet v1.0.6

This is no surprise, because as I said above:

But the 1.0.6 release is current with master branch, so there's really no difference between this and a simple composer global require valeryan/valet-wsl in terms of what would be downloaded.

I really encourage you to take the time and try this on your own system.

@valeryan
Copy link
Owner

I don't guess I get what you are on about. v1.0.6 is the latest release.

@nathan-io
Copy link
Author

nathan-io commented Aug 28, 2020

You are way too smart for me to believe you're this bad at reading comprehension. I have very clearly explained what my issue/concern is. At this point I just have to assume trolling.

Thanks for wasting my time.

@valeryan
Copy link
Owner

nathan@workstation:~/.composer$ valet --version
Valet v1.0.6

What are you expecting here beside v1.0.6. You said on one machine you are getting v3.0.0 which is not a valid release. So I assume that you would be trying to fix that machine not the one that actually has v1.0.6... Maybe you are just really bad at explaining your problem. I am waisting my free time to try and help you...

@valeryan
Copy link
Owner

So, I have read through this whole thread again. I think I know what you are confused about. I tried to explain this before but I will try to make it more specific this time. There is an official version of valet created and owned by Laravel. This package is not in any way associated with that package and does not track it in version or code commits. There is an unofficial fork for Valet for Linux that is also not officially associated with laravel valet. This package is a fork of that unofficial fork that then applies a few fixes to make it run within WSL. This package also does not track all upstream changes from that fork either and I do not track versions with that fork or the official valet. The first release of valet-wsl is v1.0.0 and the current release is v1.0.6. If you go to laravel/valet and create and issue about my package they will just tell you that you are not running on an officially supported version of valet and close your issue. Many of the forks stick with the version 2 scheme that is in place when the forked. I did not when I started this fork because It was always a tinker project that kind of helped some people including me. I don't use wsl currently but I try to keep this at least workable for people. But thanks for calling me a troll for spending my gaming time try to help you. Really appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants