8000 [DX] Smarter web server commands · Issue #21040 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[DX] Smarter web server commands #21040

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.

Sign up for GitHub

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

Jump to bottom
Closed
javiereguiluz opened this issue Dec 24, 2016 · 13 comments
Closed

[DX] Smarter web server commands #21040

javiereguiluz opened this issue Dec 24, 2016 · 13 comments
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony)

Comments

@javiereguiluz
Copy link
Member
javiereguiluz commented Dec 24, 2016 •
edited
Loading
Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? no
Symfony version 3.3

Problem

When using the server:start command in several apps, you must provide a free port number to avoid errors like this one:

$ ./bin/console server:start
  [OK] Web server listening on http://127.0.0.1:8000

(change to other app in other directory)

$ ./bin/console server:start
  [ERROR] A process is already listening on http://127.0.0.1:8000

$ ./bin/console server:start 127.0.0.1:8001
  [ERROR] A process is already listening on http://127.0.0.1:8001

$ ./bin/console server:start 127.0.0.1:8002
  [ERROR] A process is already listening on http://127.0.0.1:8002

  fffffuuuuuuuuuuuu !!!!

Solution

If it's technically possible, I'd like the server:start command to look for a free port automatically. Starting from 8000, check the following N ports and pick the first one available.

Same example as before:

$ ./bin/console server:start
  [OK] Web server listening on http://127.0.0.1:8000

(change to other app in other directory)

$ ./bin/console server:start
  [OK] Web server listening on http://127.0.0.1:8024

Depending on how fast/slow is this process, we could check 10, 100 or 1,000 ports before showing the error message.
@javiereguiluz javiereguiluz added the DX DX = Developer eXperience (anything that improves the experience of using Symfony) label Dec 24, 2016
@fabpot
Copy link
Member
fabpot commented Dec 24, 2016

The "problem" I can see is that currently, we don't have the information about which server is running on a given port. So, when a web server is running on 8000, we don't know if this is a server for the current project or from another project. I will investigate if we can "fix" that as part of my PR decoupling the web server from framework bundle.

@javiereguiluz
Copy link
Member Author

OK. I was thinking about the isOtherServerProcessRunning() method that calls the fsockopen() function. We could call that repeatedly increasing the port number until we don't get an error. (I haven't tested and I don't know if it makes sense).

@fabpot
Copy link
Member
fabpot commented Dec 24, 2016

But then, and that's just one example, we need to store the port somewhere so that the server:stop command works.

@fabpot
Copy link
Member
fabpot commented Dec 24, 2016

Working on it :)

@nicolas-grekas
Copy link
Member

What about deprecating server:start&stop and keep only server:run? Allows having some logs right into the console.

@xabbuh
Copy link
Member
xabbuh commented Dec 24, 2016

I can imagine that auto-discovery of the next free port can cause confusion if users do not read the output carefully enough and then visit their project in the browser and do not see the expected output. What about making the new behaviour opt-in with an option like --discover-port?

@javiereguiluz
Copy link
Member Author

@xabbuh do you really think that would be a problem? The output message is super short:

[OK] Web server listening on http://127.0.0.1:8024

Besides, don't people just click on that link to open the page in the browser?

@nicolas-grekas
Copy link
Member

Is it that common to have a port conflict btw?
About an option to enable the auto selection, it could be eg --port auto. But it would look inverted to me, to have to type more to enable some auto mechanism. Typing more to disable the auto logic is what looks the normal way to me.
Another idea: add a config option so that each app can have a different default port ?

@javiereguiluz
Copy link
Member Author

It happens to me all the time. Maybe it's because I work with lots of small apps simultaneously.

In my opinion, if we add an option to enable this behavior, then it's better to not implement this behavior. Remembering the name of the option and typing it would be almost the same amount of work.

@xabbuh
Copy link
Member
xabbuh commented Dec 24, 2016

Being able to configure the default port also sounds like a good idea to me. The default value could either be 8000 or auto.

@fabpot
Copy link
Member
fabpot commented Dec 24, 2016 •
edited
Loading

What about replacing the current address and --port options to a single argument:

server:run 127.0.0.1:8000
server:run 8000 # same as above
server:run 127.0.0.1 # port is 80
server:run auto # port is auto-determined starting at 8000
server:run 127.0.0.1:auto # same as above

@xabbuh
Copy link
Member
xabbuh commented Dec 24, 2016

@fabpot You can already pass the port as part of the address. Though I think it indeed makes sense to unify the unit and deprecate the --port option.

@fabpot
Copy link
Member
fabpot commented Dec 24, 2016

See #21039 (auto not implemented yet but easier now)

@fabpot fabpot mentioned this issue Jan 4, 2017
Merged
fabpot added a commit that referenced this issue Jan 6, 2017
@fabpot
feature #21039 Web server bundle (fabpot)
be85fcc 
This PR was squashed before being merged into the 3.3-dev branch (closes #21039).

Discussion
----------

Web server bundle

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | yes
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #21040
| License       | MIT
| Doc PR        | n/a

Moved the `server:*` commands to a new bundle. It makes them more easily discoverable and more decoupled. Discoverability is important when not using symfony/symfony. In that case, the commands are not available unless you have the symfony/process component installed. With a dedicated bundle, installing the bundle also installs the dependency, making the whole process easier.

Usage is the same as the current commands for basic usage:

To start a web server in the foreground:

```
bin/console server:run
```

To manage a background server:

```
bin/console server:start
bin/console server:stop
bin/console server:status
```

The big difference is that port is auto-determined if something is already listening on port 8000.

Usage is **different** if you pass options:

```
bin/console server:start 127.0.0.1:8888
bin/console server:stop # no need to pass the address again
bin/console server:status # no need to pass the address again
```

That's possible as the web server now stores its address in a pid file stored in the current directory.

Commits
-------

f39b327 [WebServerBundle] switched auto-run of server:start to off by default
961d1ce [WebServerBundle] fixed server:start when already running
126f4d9 [WebServerBundle] added support for port auto-detection
6f689d6 [WebServerBundle] changed the way we keep track of the web server
585d445 [WebServerBundle] tweaked command docs
fa7ebc5 [WebServerBundle] moved most of the logic in a new class
951a1a2 [WebServerBundle] changed wording
ac1ba77 made the router configurable via env vars
48dd2b0 removed obsolete check
132902c moved server:* command to a new bundle
@fabpot fabpot closed this as completed Jan 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DX DX = Developer eXperience (anything that improves the experience of using Symfony)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fabpot @javiereguiluz @nicolas-grekas @xabbuh
0