-
Notifications
You must be signed in to change notification settings - Fork 54
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
Added support for regex in path spec. #235
Conversation
…info element for any capture groups
I like this better than your other suggestion, especially since it's more flexible than explicitly recognizing "file extensions" as a thing. Let's see if Travis will build it correctly before we merge. Other contributors, please weigh in! |
My main weigh-in won't be directly related to this PR, but rather to the build-tidiness PR. Rubinius is usually the ruby that's making our builds fail there (though really, we need to extract the adapters to gems). I lack the time to track down exactly why this is, because we've got multiple adapters failing for subtly different reasons on multiple rubies with slightly different threading behaviours, especially around Fibers; I'd suggest we move Rubinius to the "allowed failures" list there for the time being, because it will continue to block passing checks on useful PRs like this one. |
I haven't done much with Travis, but it looks like it is failing during the bundle install install (something about spec being nil?). I was having issues running all specs locally (which fails anywhere from 13 to 90 tests, I'm assuming because of timeouts). That is with Ruby 2.3.0. Was that fixed in the build-tidiness PR? Or is there something I need to fix on my end to at least get the tests to run to the same point I'm seeing locally? |
👍 on removing all adapters except those bundled with ruby itself. |
@rfestag could you merge in the changes since the last commit? |
Done, and it looks like all checks passed. |
If no-one has objections ill merge it in the next 48 hours. |
Supports adding :captures path_info element for any capture groups.
I ran the following quick benchmark to verify that traditional (string/symbol) routes are not impacted significantly. Basically, we check whether the spec is a regex (like how Symbols work), and only then incur the overhead of regex matching and pulling out capture groups.