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

Decisions and Plan for Linux & Windows Support #196

Closed
rickmanelius opened this Issue May 3, 2017 · 24 comments

Comments

Projects
None yet
4 participants
@rickmanelius
Contributor

rickmanelius commented May 3, 2017

Overall Objective

The current team is primarily using macOS for development purposes and is not currently performing any manual testing on Linux and (more importantly) Windows. Given that we want/need to be able to support the big three (mac, Windows, and Linux), we need to ensure that they are all given a 1st class priority.

That said, we need to properly scope this so that we don’t become buried with keeping up with every distribution + version of Linux and every version of Windows. Therefore, it’s important that we find a balance point.

Acceptance Criteria

  • Test v0.1 to v0.3 functionality on Windows 10.
  • Test v0.1 to v0.3 functionality on Ubuntu 16.04.2 LTS.
  • Inventory any OS specific nuances and/or issues.
  • Determine a high level LOE for addressing said issues.
  • Decide whether or not to expand Linux support beyond Ubuntu 16.04.2 LTS.
  • Update readme to reflect current OS support.
  • Update roadmap to reflect when support for each OS will be provided.
  • When and where applicable, create additional issues to track future recommendations based on this research.

@rickmanelius rickmanelius added this to the v0.4 milestone May 3, 2017

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 4, 2017

Contributor

This is now actionable, and potentially something we can/should separate into separate issues given that multiple people could work on this in parallel.

Contributor

rickmanelius commented May 4, 2017

This is now actionable, and potentially something we can/should separate into separate issues given that multiple people could work on this in parallel.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 4, 2017

Member

FWIW, I have used on Ubuntu 14.04 without any particular trouble (but without a lot of intensity), and all of our tests run on Ubuntu 14.04. Lots of gotchas getting Windows going, but could be fun.

Member

rfay commented May 4, 2017

FWIW, I have used on Ubuntu 14.04 without any particular trouble (but without a lot of intensity), and all of our tests run on Ubuntu 14.04. Lots of gotchas getting Windows going, but could be fun.

@tannerjfco

This comment has been minimized.

Show comment
Hide comment
@tannerjfco

tannerjfco May 4, 2017

Member

I also somewhat regularly develop and test ddev on Ubuntu 16.10, and haven't hit any notable issues in the usage I've had so far. That said, I have not done any actual web development with the tool on Linux.

Member

tannerjfco commented May 4, 2017

I also somewhat regularly develop and test ddev on Ubuntu 16.10, and haven't hit any notable issues in the usage I've had so far. That said, I have not done any actual web development with the tool on Linux.

@beeradb

This comment has been minimized.

Show comment
Hide comment
@beeradb

beeradb May 4, 2017

Contributor

Our best path towards windows support in the near term may be via https://msdn.microsoft.com/en-us/commandline/wsl/about

Contributor

beeradb commented May 4, 2017

Our best path towards windows support in the near term may be via https://msdn.microsoft.com/en-us/commandline/wsl/about

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 4, 2017

Member

Stackexchange recipe for docker on Windows Bash.

Member

rfay commented May 4, 2017

Stackexchange recipe for docker on Windows Bash.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 8, 2017

Member

I did a kick-the-tires on Fedora 25 Workstation, and had no real trouble beyond understanding how to set up docker/docker-compose properly there. These are really the same problems with any linux, just slightly different varieties of setup.

  1. Install docker-ce correctly, https://docs.docker.com/engine/installation/linux/fedora
  2. Enable/start sudo systemctl start docker && sudo systemctl enable docker
  3. Add user to docker group, then log out and log back in again.
Member

rfay commented May 8, 2017

I did a kick-the-tires on Fedora 25 Workstation, and had no real trouble beyond understanding how to set up docker/docker-compose properly there. These are really the same problems with any linux, just slightly different varieties of setup.

  1. Install docker-ce correctly, https://docs.docker.com/engine/installation/linux/fedora
  2. Enable/start sudo systemctl start docker && sudo systemctl enable docker
  3. Add user to docker group, then log out and log back in again.
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 8, 2017

Contributor

Another item to consider: file mounts (capabilities, complexity, and performance). See #208.

Contributor

rickmanelius commented May 8, 2017

Another item to consider: file mounts (capabilities, complexity, and performance). See #208.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 9, 2017

Member

What I've learned so far is mostly incorporated in #209

There are at least 3 ways we can do docker on Windows:

  1. Docker For Windows - requires Windows Pro, doesn't work on Windows Home due to lack of HyperV. As a result, I haven't been able to test it. Uses binary compiled for WIndows.
  2. Docker Toolbox, which runs a Virtualbox VM. I've currently focused most effort on this one. Uses binary compiled for WIndows.
  3. A composite environment under Windows Bash, see stackexchange recipe. This will require that the $DOCKER_HOST be set correctly, the same as in option 2. I look forward to seeing if this is possible. Uses binary compiled for Linux.
  • ddev has to respect environment variables instead of assuming that everything is localhost http:
    • DOCKER_HOST in the form tcp://192.168.59.103:2375
    • DOCKER_CERT_PATH is fullpath to the ssl certificate
  • Docker toolbox uses ssl, so GetDockerClient() has to use docker.NewTLSClient() instead of just docker.NewClient(). Current code makes this decision based on existence of DOCKER_CERT_PATH.
  • Our current build works on windows in the msysgit environment (with rooted paths that don't have a colon), but only if minor change of homedir to /c/Users/ instead of c:/users. (We aren't able to run the docker run on the golang-build-container and mount it properly with a colon in the path. This is a docker issue unrelated to anything with ddev. There may be workarounds, especially if it's possible to mount a docker volume with a relative path.)
  • import-db doesn't work, I don't yet understand why.
    importPath, err := appimport.ValidateAsset(imPath, "db") doesn't seem to return the right path - all garbaged up.
  • all 4 containers are running
  • The nginx proxy container gives up every time it contacts the nginx container - the keepalive is killed.
  • I removed the ddev PrepareDirs from app init, and that broke test because .ddev/data didn't get created. Can probably do it to ensure those dirs are there instead of actually creating them (and failing).
  • The sudo+etc/hosts approach certainly doesn't work on Windows, although there may be a way to launch ddev with admin privileges another way.
  • ddev ssh doesn't work because it uses drud-go version of NewClient() (but that's fixed in Tanner's multi-compose #198)
Member

rfay commented May 9, 2017

What I've learned so far is mostly incorporated in #209

There are at least 3 ways we can do docker on Windows:

  1. Docker For Windows - requires Windows Pro, doesn't work on Windows Home due to lack of HyperV. As a result, I haven't been able to test it. Uses binary compiled for WIndows.
  2. Docker Toolbox, which runs a Virtualbox VM. I've currently focused most effort on this one. Uses binary compiled for WIndows.
  3. A composite environment under Windows Bash, see stackexchange recipe. This will require that the $DOCKER_HOST be set correctly, the same as in option 2. I look forward to seeing if this is possible. Uses binary compiled for Linux.
  • ddev has to respect environment variables instead of assuming that everything is localhost http:
    • DOCKER_HOST in the form tcp://192.168.59.103:2375
    • DOCKER_CERT_PATH is fullpath to the ssl certificate
  • Docker toolbox uses ssl, so GetDockerClient() has to use docker.NewTLSClient() instead of just docker.NewClient(). Current code makes this decision based on existence of DOCKER_CERT_PATH.
  • Our current build works on windows in the msysgit environment (with rooted paths that don't have a colon), but only if minor change of homedir to /c/Users/ instead of c:/users. (We aren't able to run the docker run on the golang-build-container and mount it properly with a colon in the path. This is a docker issue unrelated to anything with ddev. There may be workarounds, especially if it's possible to mount a docker volume with a relative path.)
  • import-db doesn't work, I don't yet understand why.
    importPath, err := appimport.ValidateAsset(imPath, "db") doesn't seem to return the right path - all garbaged up.
  • all 4 containers are running
  • The nginx proxy container gives up every time it contacts the nginx container - the keepalive is killed.
  • I removed the ddev PrepareDirs from app init, and that broke test because .ddev/data didn't get created. Can probably do it to ensure those dirs are there instead of actually creating them (and failing).
  • The sudo+etc/hosts approach certainly doesn't work on Windows, although there may be a way to launch ddev with admin privileges another way.
  • ddev ssh doesn't work because it uses drud-go version of NewClient() (but that's fixed in Tanner's multi-compose #198)
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 9, 2017

Contributor

Initial Feedback to @rfay's review of Windows #196 (comment).

  • Option 1: Windows Pro does add a $200 cost, which might price out people.
  • Option 2: Docker Toolbox. My only concern is that this adds a layer of abstraction in the way. Essentially, one needs a VM in order to then run containers. At that point, I can see some end-users simply opting for a straight up VM solution, although we do have the advantage of being able to be a singular tool that works with multiple providers.
  • Option 3: This to me seems like it would be the one that would best balance adoption and not creating the overhead of using an additional VM to use a docker solution. I'm biased towards exploring this more, even if it adds a bit more to the setup/installation efforts. It also seems like it could work in parallel to those that can opt for the Windows Pro version.

There is a lot to consider here, but I would imagine that if cost is a driving factor, an end-user might be more likely to adopt Ubuntu. Of course there are a lot of people using cheap windows laptops without a significant amount of RAM. That's where option 3 might provide them a path forward without the overhead of a VM.

Regarding your testing, it does sound like we'd have to audit certain functionality so that our commands work universally. I'm assuming once your PR is accepted, we can run all of our unit tests against Windows so we can chase down these discrepancies while not introducing regressions on macOS?

Contributor

rickmanelius commented May 9, 2017

Initial Feedback to @rfay's review of Windows #196 (comment).

  • Option 1: Windows Pro does add a $200 cost, which might price out people.
  • Option 2: Docker Toolbox. My only concern is that this adds a layer of abstraction in the way. Essentially, one needs a VM in order to then run containers. At that point, I can see some end-users simply opting for a straight up VM solution, although we do have the advantage of being able to be a singular tool that works with multiple providers.
  • Option 3: This to me seems like it would be the one that would best balance adoption and not creating the overhead of using an additional VM to use a docker solution. I'm biased towards exploring this more, even if it adds a bit more to the setup/installation efforts. It also seems like it could work in parallel to those that can opt for the Windows Pro version.

There is a lot to consider here, but I would imagine that if cost is a driving factor, an end-user might be more likely to adopt Ubuntu. Of course there are a lot of people using cheap windows laptops without a significant amount of RAM. That's where option 3 might provide them a path forward without the overhead of a VM.

Regarding your testing, it does sound like we'd have to audit certain functionality so that our commands work universally. I'm assuming once your PR is accepted, we can run all of our unit tests against Windows so we can chase down these discrepancies while not introducing regressions on macOS?

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 9, 2017

Contributor

A reminder, the scope of this ticket is testing, getting an inventory of OS specific discrepancies, and getting to a decision on what we'll support and when in the roadmap. So far things look promising, and we can plan on support (with caveats) for some Linux variants and Windows 10.

Contributor

rickmanelius commented May 9, 2017

A reminder, the scope of this ticket is testing, getting an inventory of OS specific discrepancies, and getting to a decision on what we'll support and when in the roadmap. So far things look promising, and we can plan on support (with caveats) for some Linux variants and Windows 10.

@beeradb

This comment has been minimized.

Show comment
Hide comment
@beeradb

beeradb May 9, 2017

Contributor

Just a note, we are using goodhosts for host file management. It does claim to have windows support. Making that work is probably more a matter of figuring out privilege escalation (strongly assuming it's needed) on windows.

Contributor

beeradb commented May 9, 2017

Just a note, we are using goodhosts for host file management. It does claim to have windows support. Making that work is probably more a matter of figuring out privilege escalation (strongly assuming it's needed) on windows.

@tannerjfco

This comment has been minimized.

Show comment
Hide comment
@tannerjfco

tannerjfco May 9, 2017

Member
  • It looks like Windows 10 Home users can upgrade to Pro for $100 vs $200. Whether or not their machine shipped with Pro depends on whether they bought a personal or business class machine, or otherwise chose to upgrade to Pro at time of purchase. Still noteworthy that Docker for Windows support could mean an additional expense to users. It would be helpful to understand how many users in our demographic are running Home vs Pro, but unfortunately I couldn't find any existing public data with that specificity. Overall, I do think targeting Docker for Windows should be our end goal.
  • I'm wary of working to provide support for what's considered the legacy desktop solution by Docker. It seems like most efforts moving forward are focused on Docker for Mac & Windows. This would also mean another virtualization environment with performance issues to contend with. I think our efforts are best focused ensuring best performance possible leveraging virtualization from the OS
  • I'm in favor of supporting this approach, but not certain where it fits in. If it's a quick way to get Windows support soon, then I'm for doing it with the expectation we would circle back for proper Windows support. It may also prove to be a nice to have that should be considered down the road. It's worth noting WSL is very much in beta, and things could still change quite a bit as it evolves. We also don't know if this feature will end up being a Pro-only feature once it reaches maturity, or if it will continue to be available for all editions.
Member

tannerjfco commented May 9, 2017

  • It looks like Windows 10 Home users can upgrade to Pro for $100 vs $200. Whether or not their machine shipped with Pro depends on whether they bought a personal or business class machine, or otherwise chose to upgrade to Pro at time of purchase. Still noteworthy that Docker for Windows support could mean an additional expense to users. It would be helpful to understand how many users in our demographic are running Home vs Pro, but unfortunately I couldn't find any existing public data with that specificity. Overall, I do think targeting Docker for Windows should be our end goal.
  • I'm wary of working to provide support for what's considered the legacy desktop solution by Docker. It seems like most efforts moving forward are focused on Docker for Mac & Windows. This would also mean another virtualization environment with performance issues to contend with. I think our efforts are best focused ensuring best performance possible leveraging virtualization from the OS
  • I'm in favor of supporting this approach, but not certain where it fits in. If it's a quick way to get Windows support soon, then I'm for doing it with the expectation we would circle back for proper Windows support. It may also prove to be a nice to have that should be considered down the road. It's worth noting WSL is very much in beta, and things could still change quite a bit as it evolves. We also don't know if this feature will end up being a Pro-only feature once it reaches maturity, or if it will continue to be available for all editions.
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 9, 2017

Contributor

My vote for Windows would be short term option 3 (WSL) mid to long term option 1 (Docker for Windows). If the team feels strongly enough to invert them, then we will need to purchase licenses sooner rather than later. Also, can we run Circle CI tests against Pro?

I personally have little interest in option 2 because I think it will hit its end of life in the near future and it adds more overhead than it's worth, but like Tanner called out, I'm not sure what market demographics are to make an informed decision with actual data.

Contributor

rickmanelius commented May 9, 2017

My vote for Windows would be short term option 3 (WSL) mid to long term option 1 (Docker for Windows). If the team feels strongly enough to invert them, then we will need to purchase licenses sooner rather than later. Also, can we run Circle CI tests against Pro?

I personally have little interest in option 2 because I think it will hit its end of life in the near future and it adds more overhead than it's worth, but like Tanner called out, I'm not sure what market demographics are to make an informed decision with actual data.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 9, 2017

Member

We dan't run circle tests against any windows project, sadly. There are probably other services that allow us to do windows.

I still hope to get to WSL today, but can't claim that it's do-able at this point.

Member

rfay commented May 9, 2017

We dan't run circle tests against any windows project, sadly. There are probably other services that allow us to do windows.

I still hope to get to WSL today, but can't claim that it's do-able at this point.

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 9, 2017

Contributor

So far the focus of this ticket has largely been on Windows, and that is fair given the concern that supporting Windows will be a much heavier lift than Linux. However, I would like to nail down what we officially support on the Linux side while providing the caveat that users with other distributions can certainly try. I also imagine that this selection might be influenced the the OS selection we use for other DRUD products in production, but that need not be a strict requirement.

Contributor

rickmanelius commented May 9, 2017

So far the focus of this ticket has largely been on Windows, and that is fair given the concern that supporting Windows will be a much heavier lift than Linux. However, I would like to nail down what we officially support on the Linux side while providing the caveat that users with other distributions can certainly try. I also imagine that this selection might be influenced the the OS selection we use for other DRUD products in production, but that need not be a strict requirement.

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 9, 2017

Contributor

Thanks, @rfay! That nuance (not being able to test with Circle CI) might warrant a caveat "we support, but cannot run automated tests to capture regressions".

Contributor

rickmanelius commented May 9, 2017

Thanks, @rfay! That nuance (not being able to test with Circle CI) might warrant a caveat "we support, but cannot run automated tests to capture regressions".

@beeradb

This comment has been minimized.

Show comment
Hide comment
@beeradb

beeradb May 9, 2017

Contributor

My vote is to commit to supporting Ubuntu/Debian/Fedora. I think we can commit to good-faith effort on all other distros as well, but the more obscure the distro you use, the more patient you are going to need to be if issues pop up. I think people running fringe distros like gentoo generally have a frontier mentaility anyway :)

Contributor

beeradb commented May 9, 2017

My vote is to commit to supporting Ubuntu/Debian/Fedora. I think we can commit to good-faith effort on all other distros as well, but the more obscure the distro you use, the more patient you are going to need to be if issues pop up. I think people running fringe distros like gentoo generally have a frontier mentaility anyway :)

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 10, 2017

Contributor

@beeradb That list works for me re:Linux. We may need to specify version numbers (e.g. Ubuntu 16.04 LTS) or parameters (Ubuntu: 2 Most Current LTS Versions). Assuming the former, I would suggest we state:

  • Ubuntu 16.04 LTS
  • Debian Jessie
  • Fedora 25

And then note, as you've mentioned, that older versions and other variants may work but require a little more hand-holding/tweaking.

Contributor

rickmanelius commented May 10, 2017

@beeradb That list works for me re:Linux. We may need to specify version numbers (e.g. Ubuntu 16.04 LTS) or parameters (Ubuntu: 2 Most Current LTS Versions). Assuming the former, I would suggest we state:

  • Ubuntu 16.04 LTS
  • Debian Jessie
  • Fedora 25

And then note, as you've mentioned, that older versions and other variants may work but require a little more hand-holding/tweaking.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 11, 2017

Member

We have a lot of technical capability here. There are significant issue to be considered besides that:

  1. Support level required. For example, if we support 3 versions of Linux, we probably have to document the Docker install on each separately. And we certainly need a way to replicate customer environments.
  2. Infrastructure (and infra maintenance) requirements: For Windows, for example, we really would need automated testing, which means we have to get it and maintain it, and then solve bugs that come up.
Member

rfay commented May 11, 2017

We have a lot of technical capability here. There are significant issue to be considered besides that:

  1. Support level required. For example, if we support 3 versions of Linux, we probably have to document the Docker install on each separately. And we certainly need a way to replicate customer environments.
  2. Infrastructure (and infra maintenance) requirements: For Windows, for example, we really would need automated testing, which means we have to get it and maintain it, and then solve bugs that come up.

rfay added a commit that referenced this issue May 11, 2017

Basic building with WIndows for #196 (#209)
* Basic building with WIndows

* Improve error message when creating docker network

* Should not prepare directories when we already have .ddev and an app configured

* Don't try to add to hosts file if no sudo available

* Support docker TLSClient, not just http client

* circle: Build windows by default, provide as artifact

* Move prepLocalSiteDirs() to local in config, check error

* Minor fixup after multi-compose PR went in

* Remove assertion that is not valid now that .ddev and subdirs are created in config

* Use actual docker ip instead of just assuming localhost

* Improve prepLocalSiteDirs() so not dependent on text content of error

* Remove assertion of site directory existence because config creation makes it now

* Use filepath instead of path for getting base filename in importdb

* Improve host parsing out of tcp://192.168.99.100:2376

* Update to use filepath instead of path everywhere

* use NewClientFromEnv to return client

* update exec help to use double quotes around cmd vs single
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 12, 2017

Contributor

Updated the issue summary to reflect the remaining items. Once we have the final Windows report (OS pain points, LOE to address, specifics on the methodology we will support), we can update the roadmap regarding when we will support Windows and to what extent.

Contributor

rickmanelius commented May 12, 2017

Updated the issue summary to reflect the remaining items. Once we have the final Windows report (OS pain points, LOE to address, specifics on the methodology we will support), we can update the roadmap regarding when we will support Windows and to what extent.

rickmanelius added a commit that referenced this issue May 12, 2017

Updating w/outcome of /issues/196
See additional commentary here (#196 (comment)) for Linux support and here (#196 (comment)) for Windows support.

rickmanelius added a commit that referenced this issue May 12, 2017

Updating w/outcome of /issues/196 (#220)
* Updating w/outcome of /issues/196

See additional commentary here (#196 (comment)) for Linux support and here (#196 (comment)) for Windows support.

* Added the missing portion of the last sentence.

* Updated install instructions to reflect OS support.

* manual install instructions for windows
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 12, 2017

Contributor

While this ticket is technically still open to get the documentation regarding OS specific issues, the primary outcomes intended for v0.4 from the perspective of an end-user have been achieved. Updating the issue summary to note future items and outcomes from this thread will be moved to other issues.

Contributor

rickmanelius commented May 12, 2017

While this ticket is technically still open to get the documentation regarding OS specific issues, the primary outcomes intended for v0.4 from the perspective of an end-user have been achieved. Updating the issue summary to note future items and outcomes from this thread will be moved to other issues.

@rfay

This comment has been minimized.

Show comment
Hide comment
@rfay

rfay May 17, 2017

Member

WIndows Comments:

Windows caveats:

  • Version: I recommend that we support Windows 10 Professional using the Windows build of ddev. There are multiple other approaches and permutations, and some of them actually work, but I believe this is the mainline approach. Windows 10 Pro is a $99 upgrade to Windows Home, and should be pretty common out there.
  • Docker for Windows only (not docker toolbox)

Infrastructure and planning:

  • We need automated testing (discussed below)
  • /etc/hosts management may need to be improved (Currently it asks for the site to be added to /etc/hosts even if it's there) - Also we may want to figure out how to allow them to do this automatically.

Documentation:

  • We probably need separate basic documentation for Windows. Otherwise it will be stilted and hard to test. I wouldn't be surprised if it can link to some of the same things, but really we should be talking about ddev.exe and using windows paths, etc.

Building and testing

  • Currently building and testing are best done using make, and the whole system is notoriously hard to use on Windows because it uses unix tools like rm and yet has to use the windows docker.exe. It may be a rethink for us to build on Windows - build-tools is definitely not set up for it.
  • Full testing is normally done via make, which is not currently working. We can probably find a technique, but it's awfully hard right now.
  • We need automated testing. The only integration listing in github's integration listing that mentions windows is Appveyor. It is free for open-source projects, which is nice. The private repo price plans run from $29-$99.

To me the biggest concern right now is building and testing, because I've broken my head on it from a few different angles. I think maybe working together with another team member we might come up with an alternate approach, but I'm stuck right now. Also, my current Windows machine is horrendously slow, which tends to put an end to things.

If Windows is important to us (probably) we'll have to actually use it a bit more to see what the actual results are in action.

Member

rfay commented May 17, 2017

WIndows Comments:

Windows caveats:

  • Version: I recommend that we support Windows 10 Professional using the Windows build of ddev. There are multiple other approaches and permutations, and some of them actually work, but I believe this is the mainline approach. Windows 10 Pro is a $99 upgrade to Windows Home, and should be pretty common out there.
  • Docker for Windows only (not docker toolbox)

Infrastructure and planning:

  • We need automated testing (discussed below)
  • /etc/hosts management may need to be improved (Currently it asks for the site to be added to /etc/hosts even if it's there) - Also we may want to figure out how to allow them to do this automatically.

Documentation:

  • We probably need separate basic documentation for Windows. Otherwise it will be stilted and hard to test. I wouldn't be surprised if it can link to some of the same things, but really we should be talking about ddev.exe and using windows paths, etc.

Building and testing

  • Currently building and testing are best done using make, and the whole system is notoriously hard to use on Windows because it uses unix tools like rm and yet has to use the windows docker.exe. It may be a rethink for us to build on Windows - build-tools is definitely not set up for it.
  • Full testing is normally done via make, which is not currently working. We can probably find a technique, but it's awfully hard right now.
  • We need automated testing. The only integration listing in github's integration listing that mentions windows is Appveyor. It is free for open-source projects, which is nice. The private repo price plans run from $29-$99.

To me the biggest concern right now is building and testing, because I've broken my head on it from a few different angles. I think maybe working together with another team member we might come up with an alternate approach, but I'm stuck right now. Also, my current Windows machine is horrendously slow, which tends to put an end to things.

If Windows is important to us (probably) we'll have to actually use it a bit more to see what the actual results are in action.

@rickmanelius rickmanelius self-assigned this May 18, 2017

@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 18, 2017

Contributor

Hi @rfay. Thanks for this. I've updated the issue summary to indicate the summarization of the pain points and the assumption that this is a relative high LOE (assumed > 1 week to address these items). Seems we need to break out tickets related to the following:

  • Documentation:
    • Specifying the supported Windows approach (Windows 10 Pro).
    • Specifying specific installation instructions.
  • Build/Testing:
    • Improvements to the process so we have automated test coverage and better build support.
  • Windows Compatibility
    • Addressing areas where linux/macOS assumptions fail (/etc/hosts, linux commands, .exe naming convention requirements on Windows, etc.).
Contributor

rickmanelius commented May 18, 2017

Hi @rfay. Thanks for this. I've updated the issue summary to indicate the summarization of the pain points and the assumption that this is a relative high LOE (assumed > 1 week to address these items). Seems we need to break out tickets related to the following:

  • Documentation:
    • Specifying the supported Windows approach (Windows 10 Pro).
    • Specifying specific installation instructions.
  • Build/Testing:
    • Improvements to the process so we have automated test coverage and better build support.
  • Windows Compatibility
    • Addressing areas where linux/macOS assumptions fail (/etc/hosts, linux commands, .exe naming convention requirements on Windows, etc.).
@rickmanelius

This comment has been minimized.

Show comment
Hide comment
@rickmanelius

rickmanelius May 19, 2017

Contributor

Placeholder children issues created. Closing out! Thanks, everyone on this HUGE issue!!!

Contributor

rickmanelius commented May 19, 2017

Placeholder children issues created. Closing out! Thanks, everyone on this HUGE issue!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment