Triage: galaxyproject/galaxy #21896 - Eliminate WSGI App for ToolShed

FEATURE_21896.md

Issue #21896: Eliminate WSGI App for ToolShed

• State: OPEN
• Author: jmchilton
• Labels: (none)
• Comments: 0
• Reactions: 0
• Project: Galaxy Dev - weeklies (Triage/Discuss)
• Milestone: (none)
• Created: 2026-02-19

Description

The issue author (jmchilton) is working through tool shed cleanup and notes that while Claude (AI) is eager to eliminate the WSGI app, the author considers it "maybe too potentially disruptive" and is deferring it personally. The WSGI shim for hg (Mercurial) is considered acceptable for now. The issue is filed so someone else could pick it up after other cleanup work lands.

Current State

Request lifecycle:

1. fast_factory.py:factory() calls buildapp.app_pair() to create WSGI CommunityWebApplication
2. fast_app.py:initialize_fast_app() wraps WSGI app via WSGIMiddleware (a2wsgi), mounts at /
3. Any request not matched by FastAPI falls through to WSGI

WSGI app serves exactly two functional routes:

• /repository/static/images/{id}/{image_file} -- tool help images from hg repos
• /repos/*path_info -- mercurial HTTP clone via hgwebdir

Plus middleware (wrap_in_middleware) and a legacy redirect (_map_redirects).

Proposed Architecture

• Image serving: Pure FastAPI endpoint (trivial file serving)
• Hg clone: Mount hgwebdir directly as WSGI sub-app under /repos via a2wsgi.WSGIMiddleware
• Redirect: FastAPI RedirectResponse
• Middleware: Drop entirely (FastAPI handles it)
• RemoteUser middleware: Drop (no longer supported)

Steps (9 total)

1. Add FastAPI image serving endpoint
2. Add FastAPI redirect for legacy endpoint
3. Mount hgwebdir as direct WSGI sub-app
4. Remove the WSGI fallback mount
5. Extract standalone app factory
6. Clean up url_for usage
7. Delete dead code (8+ files, 2 directories)
8. Update test_context.py
9. Remove unused dependencies (Paste, Routes)

Unresolved Questions

• hgwebdir PATH_INFO rewriting verification
• hgwebdir thread safety
• url_for fallback usage
• config_manage.py reference handling
• WebOb transitive dependency check
• SQLAlchemy session scoping in hg handler

FEATURE_21896_CODE_RESEARCH.md

Code Research: Issue #21896 -- Eliminate WSGI App for ToolShed

Current Architecture

The WSGI Stack

The ToolShed runs a dual-stack architecture: a FastAPI app with a full WSGI app mounted as a catch-all fallback at /.

Entry point: lib/tool_shed/webapp/fast_factory.py

factory() -> app_pair() -> initialize_fast_app(gx_webapp, app)

1. fast_factory.py:factory() creates both apps
2. buildapp.py:app_pair() constructs the full WSGI CommunityWebApplication with Routes, controllers, middleware
3. fast_app.py:initialize_fast_app() wraps it via WSGIMiddleware(gx_webapp) and mounts at /

What the WSGI App Actually Serves

Analysis of buildapp.py shows the WSGI app has extensive route definitions, but with the TS2.0 FastAPI endpoints in place, only two functional routes still require WSGI:

1. Image serving (/repository/static/images/{repository_id}/{image_file})

   • Controller: controllers/repository.py:display_image_in_repository() (line 805)
   • Reads image files from hg repository working directories
   • Uses datatypes_registry.get_mimetype_by_extension() for MIME types
   • ~30 lines of logic, trivially replaceable with FastAPI FileResponse

2. Mercurial HTTP clone (/repos/*path_info)

   • Controller: controllers/hg.py:HgController.handle_request() (49 lines total)
   • Creates hgwebdir instance per request from hgweb_config
   • Tracks download counts (increments times_downloaded on getbundle command)
   • Checks for deprecated repositories
   • Returns a WSGI middleware wrapping hgwebdir

Plus one redirect handled by Routes middleware:

• /repository/status_for_installed_repository -> /api/repositories/updates/ (301)
• Implemented in buildapp.py:_map_redirects() using Routes mapper

WSGI Middleware Stack

buildapp.py:wrap_in_middleware() applies these layers (all replaceable or removable):

Middleware	Purpose	FastAPI equivalent
httpexceptions (Paste)	HTTP error handling	Built-in
RoutesMiddleware	Redirect mapping	RedirectResponse
RemoteUser	Remote user auth	No longer supported per issue
TransLogger (Paste)	Access logging	Uvicorn/Gunicorn logging
XForwardedHostMiddleware	Proxy header handling	Built-in / Starlette
RequestIDMiddleware	Request ID tracking	Already added to FastAPI app
ErrorMiddleware	Error handling	add_exception_handler() already in FastAPI app

Files Proposed for Deletion

File	Lines	Purpose
lib/tool_shed/webapp/buildapp.py	330	WSGI app factory, routes, middleware
lib/tool_shed/webapp/controllers/repository.py	2,647	WSGI controllers (mostly legacy UI)
lib/tool_shed/webapp/controllers/hg.py	49	Mercurial HTTP clone handler
lib/tool_shed/webapp/controllers/__init__.py	1	Package init
lib/tool_shed/webapp/controllers/admin.py	501	Admin UI controller (legacy)
lib/tool_shed/webapp/controllers/groups.py	16	Groups controller
lib/tool_shed/webapp/controllers/user.py	464	User controller (legacy)
lib/tool_shed/webapp/framework/middleware/remoteuser.py	129	Remote user middleware
lib/tool_shed/webapp/framework/middleware/__init__.py	1	Package init
lib/tool_shed/webapp/framework/decorators.py	25	require_login decorator
lib/tool_shed/webapp/framework/__init__.py	3	Package init
Total	~4,166

Note: The issue lists 8 files but the controllers directory also contains admin.py, groups.py, and user.py which would also be removed (they are only used by the WSGI app).

Files Requiring Modification

File	Change	Complexity
lib/tool_shed/webapp/fast_factory.py	Remove app_pair() import, create app directly	Low
lib/tool_shed/webapp/fast_app.py	Remove WSGI mount, add hg sub-app mount	Medium
lib/tool_shed/util/common_util.py	Remove from routes import url_for fallback	Low
lib/tool_shed/util/shed_util_common.py	Remove url_for fallback	Low
lib/tool_shed/util/repository_util.py	Remove web.url_for usage (lines 138, 255)	Low
lib/tool_shed/util/readme_util.py	Remove web.url_for usage (line 78)	Low
lib/tool_shed/util/admin_util.py	Massive web.url_for usage (40+ instances) -- but entire file may be dead code if admin controllers are removed	Unclear
lib/tool_shed/test/base/driver.py	Update webapp_factory usage	Medium
lib/galaxy/config/config_manage.py	Update tool_shed.webapp.buildapp:app_factory reference	Low

New Files Needed

File	Purpose
lib/tool_shed/webapp/api2/repository_images.py	FastAPI image serving endpoint

FastAPI Migration Progress

The ToolShed already has a complete FastAPI API surface in lib/tool_shed/webapp/api2/:

• authenticate.py -- authentication endpoints
• categories.py -- category management
• configuration.py -- config/version
• repositories.py -- repository CRUD, metadata, updates
• tools.py -- tool search/listing
• users.py -- user management

The SHED_API_VERSION env var (v1 or v2) controls which API layer is active. The v2 frontend (TS2.0) is fully functional. The WSGI v1 API routes in buildapp.py overlap with v2 FastAPI routes.

Dependency Impact

Dependency	Current Usage in ToolShed	Can Remove?
Paste	buildapp.py only (httpexceptions, TransLogger)	Yes
Routes	buildapp.py + common_util.py url_for fallback	Yes (after url_for cleanup)
a2wsgi	fast_app.py WSGI mount	Keep (still needed for hg sub-app)
Mako	readme_util.py	Keep (independent of WSGI)
mercurial	controllers/hg.py	Keep (hgwebdir still needed)

Comparison: Galaxy Main App

The main Galaxy app (lib/galaxy/webapps/galaxy/fast_app.py) still uses the identical WSGI-fallback pattern:

wsgi_handler = WSGIMiddleware(gx_wsgi_webapp)

The ToolShed elimination would serve as a proof of concept for eventually doing the same in the main Galaxy app, though Galaxy's WSGI surface is vastly larger.

Key Risk: hgwebdir Integration

The most complex part of this change is the Mercurial hgwebdir integration. Currently it runs inside the full WSGI request lifecycle with session management, URL routing, and error handling. Moving it to a standalone WSGI sub-app requires:

1. PATH_INFO rewriting: hgwebdir expects /repos/owner/name in PATH_INFO, but Starlette strips the mount prefix
2. Session management: Download tracking (times_downloaded increment) currently uses the WSGI app's request-scoped SQLAlchemy session
3. Thread safety: Current code creates a new hgwebdir instance per request; caching may or may not be safe
4. Error handling: Deprecated repo checks need to produce proper HTTP errors outside the WSGI error middleware

url_for Dependency Analysis

The url_for function from Routes is used as a fallback in several places when no trans or hostname is available. These are:

• common_util.py:43 -- url_for("/", qualified=True) as hostname fallback
• shed_util_common.py:379 -- same pattern
• repository_util.py:138,255 -- web.url_for("/", qualified=True) for base URL
• readme_util.py:78 -- static path and host URL generation
• admin_util.py -- 40+ instances for controller/action URL generation (but admin_util is only used by the admin controller, which is itself WSGI-only)

The Routes url_for requires the Routes mapper to be configured, which currently happens through the WSGI app. Removing WSGI means these fallback paths would break. The fix is to require hostname from config or trans context in all cases.

FEATURE_21896_DEMAND.md

Demand Research: Issue #21896 -- Eliminate WSGI App for ToolShed

Quantified Demand

Reactions & Engagement

• Thumbs up: 0
• Total reactions: 0
• Comments: 0
• Created: 2026-02-19 (5 days old at time of triage)

Linked / Duplicate Issues

No linked or duplicate issues found. This is a fresh issue, not a long-standing community request.

Related Issues & Context

Issue	Title	State	Relevance
#12257	Roadmap to FastAPI	Closed	The parent effort; Galaxy main app completed WSGI-to-FastAPI migration for most endpoints. Tool Shed was not in scope.
#10889	Progressively adapt old API routes to FastAPI	Open	Broad FastAPI migration tracking.
#15639	Tool Shed 2.0	Closed	TS2.0 introduced the FastAPI-based frontend. The WSGI layer survived as a fallback.
#19693	Pin mercurial for Python 3.12	Closed	Mercurial dependency is directly related -- hg clone is the main reason WSGI persists.

Author Context

• Filed by jmchilton, a core maintainer and the primary driver of tool shed modernization.
• The issue is explicitly self-deferred: "I think this little shim for hg is fine so I'm putting this off personally."
• Part of a broader cleanup effort; jmchilton mentions a forthcoming PR that removes "tons of legacy stuff."
• The detailed 9-step plan was AI-generated (Claude), suggesting this was exploratory research rather than imminent work.

Community Discussion

• No external discussion threads found on Galaxy Dev mailing list or Gitter/Matrix.
• No mentions in Galaxy Training Network or admin documentation requests.
• The ToolShed is a shared community resource but has a small active maintainer base (primarily jmchilton, mvdbeek, guerler).

Demand Assessment

User demand: LOW

This is an internal tech debt issue, not a user-facing feature request. No community members have requested it, reacted to it, or commented on it. The issue was filed as a "maybe someday" placeholder by its author. The WSGI layer is invisible to end users -- it handles hg clone and image serving, both of which work fine today.

The demand is entirely developer-side: reducing maintenance burden, simplifying the codebase, and removing legacy dependencies. While that has real value, there is no external pressure to prioritize this.

FEATURE_21896_IMPORTANCE.md

Importance Assessment: Issue #21896 -- Eliminate WSGI App for ToolShed

User Demand: LOW

• Zero reactions, zero comments on a 5-day-old issue
• No related community requests or discussion threads
• Filed by a core maintainer as a self-deferred placeholder
• The WSGI layer is invisible to end users
• The only externally-visible behavior (hg clone, image serving) works correctly today

Strategic Value: MEDIUM-HIGH

This is not about user demand -- it is about codebase health and maintainability.

Positive strategic factors:

• Removes ~4,100 lines of legacy code (controllers, middleware, framework)
• Eliminates Paste and Routes as ToolShed dependencies
• Simplifies the application startup path (no more dual WSGI+FastAPI stack)
• Reduces the mental overhead for anyone working on ToolShed code
• Serves as a proof-of-concept for eventually eliminating WSGI from the main Galaxy app
• Aligns with the long-running FastAPI migration strategy (issue #12257)
• jmchilton is actively cleaning up the ToolShed; this fits naturally into that arc

Tempering factors:

• The WSGI shim works and does not actively cause problems
• The ToolShed has a small user base relative to Galaxy itself
• The code being removed is mostly inert -- it is legacy but not actively causing bugs
• Galaxy main app still uses the same pattern, so this does not eliminate WSGI from the project entirely

Effort Estimate: MEDIUM

The issue comes with a detailed 9-step implementation plan, which is both a blessing and a source of concern.

What makes it medium rather than small:

• 9 distinct steps with ordering dependencies
• hgwebdir PATH_INFO rewriting needs careful testing with actual Mercurial wire protocol
• SQLAlchemy session scoping for the standalone hg WSGI sub-app is non-trivial
• url_for fallback cleanup touches multiple utility modules
• Test driver updates require understanding the test infrastructure
• Several unresolved questions in the issue that need answers before implementation
• Functional testing requires a running ToolShed with Mercurial

What keeps it from being large:

• The plan is well-researched and specific
• Most individual steps are small (FastAPI endpoint, redirect, delete files)
• The most complex piece (hgwebdir sub-app) is ~50 lines of new code
• The majority of the work is deletion

Estimated effort: 2-4 days for an experienced Galaxy developer, assuming the unresolved questions do not surface surprises. Add buffer time for hg protocol testing.

Risk Assessment: MODERATE

Disruption Risk

The issue author explicitly flags this: "I think it is maybe too potentially disruptive." This concern is valid.

Breaking change vectors:

1. hg clone: If the PATH_INFO rewriting is wrong, Mercurial clone/push operations break for all ToolShed users
2. Image serving: If the FastAPI endpoint has different path matching behavior, tool help images break
3. Session scoping: If the hg download tracking loses its session, download counts silently stop incrementing
4. url_for fallback: If any code path calls url_for without trans/hostname, it will crash at runtime rather than failing gracefully
5. Test infrastructure: Changes to driver.py could break the ToolShed test suite, which is already fragile

Mitigating factors:

• The ToolShed has functional tests covering hg clone and image serving
• The WSGI surface is very small (2 routes + 1 redirect)
• Changes can be staged incrementally (steps 1-2 first, then 3-4, etc.)
• The v1 API is still the default; v2 is opt-in via environment variable

Timing Risk

• jmchilton has a pending PR removing "tons of legacy stuff" -- this change should wait for that to land
• Doing this concurrently with other ToolShed cleanup risks merge conflicts
• The issue was filed as a "park it for later" item, not an urgent need

Maintenance Risk (of NOT doing it)

• Every release cycle, the dual WSGI+FastAPI stack adds cognitive overhead
• Paste and Routes are aging dependencies with declining maintenance
• New developers hitting ToolShed code face unnecessary complexity
• The longer legacy code sits, the harder it is to reason about what is actually used

Recommendation: BACKLOG

Rationale: This is good, well-scoped work that aligns with the project's long-term direction. However, it should not be prioritized ahead of user-facing features or bug fixes given zero user demand. The right time to do this is:

1. After jmchilton's pending ToolShed cleanup PR lands
2. When someone is already working in the ToolShed codebase
3. Ideally early in a release cycle to allow time for regression discovery

The issue is well-documented enough that it can be picked up at any time. It would be a good task for a developer looking to deepen their understanding of the ToolShed architecture.

Do not decline: The work has clear value and a solid plan. It just does not have urgency.

FEATURE_21896_PLAN.md

Implementation Plan: Issue #21896 -- Eliminate WSGI App for ToolShed

Prerequisites

• jmchilton's pending ToolShed cleanup PR must land first. That PR removes "tons of legacy stuff" and will change the baseline for this work.
• Verify which controllers and utility code survive that cleanup before starting.

Recommended Approach: Incremental PRs

Rather than one large PR (which the issue author already flagged as "too potentially disruptive"), this should be split into 2-3 smaller PRs that can be reviewed and tested independently.

PR 1: Add FastAPI replacements (non-breaking, additive only)

Goal: Add the FastAPI endpoints that will replace WSGI routes, without removing anything. Both stacks coexist; FastAPI matches first.

Step 1a: Image serving endpoint

Create lib/tool_shed/webapp/api2/repository_images.py:

# New FastAPI endpoint for repository images
# GET /repository/static/images/{repository_id}/{image_file:path}
# Returns FileResponse with mimetypes.guess_type() for MIME detection
# include_in_schema=False (internal route)

Key decisions:

• Use mimetypes.guess_type() instead of datatypes_registry.get_mimetype_by_extension()
• Return proper 404 for missing repos/files
• Register in api2/__init__.py router list

Step 1b: Legacy redirect

Add to repository_images.py or a new redirects.py:

# GET /repository/status_for_installed_repository -> 301 /api/repositories/updates/
# Preserve query parameters

Testing: Deploy and verify both old and new endpoints serve identical responses.

Affected files:

• New: lib/tool_shed/webapp/api2/repository_images.py
• Modified: lib/tool_shed/webapp/api2/__init__.py (register new router)

PR 2: Replace WSGI fallback with targeted hg sub-app

Goal: Replace the full WSGI app mount with a minimal hgwebdir WSGI sub-app.

Step 2a: Create hgwebdir WSGI wrapper

In lib/tool_shed/webapp/fast_app.py, add a class or function that:

• Wraps hgwebdir from mercurial
• Fixes SERVER_PORT to string (mercurial requirement, currently in PortAsStringMiddleware)
• Prepends /repos to PATH_INFO (Starlette strips mount prefix)
• Loads hgweb_config from app.hgweb_config_manager
• Tracks download counts on getbundle command
• Returns 404 for deprecated repositories
• Manages its own SQLAlchemy session for download tracking

Critical: Test this thoroughly with actual Mercurial operations:

hg clone http://localhost:9009/repos/user1/some_repo /tmp/test_clone
hg pull http://localhost:9009/repos/user1/some_repo
# Verify capabilities, getbundle, and other wire protocol commands

Step 2b: Mount hg sub-app, remove WSGI fallback

In fast_app.py:initialize_fast_app():

• Remove WSGIMiddleware(gx_webapp) mount at /
• Add hg WSGI sub-app mount at /repos
• Remove gx_webapp parameter

Step 2c: Update fast_factory.py

• Remove from tool_shed.webapp.buildapp import app_pair
• Create ToolShed app directly (extract from buildapp.py:app_pair())
• Pass only the app to initialize_fast_app()

Affected files:

• lib/tool_shed/webapp/fast_app.py (major changes)
• lib/tool_shed/webapp/fast_factory.py (moderate changes)

PR 3: Clean up dead code and dependencies

Goal: Remove everything that is no longer reachable.

Step 3a: url_for cleanup

Fix the Routes url_for fallback in:

• lib/tool_shed/util/common_util.py:43 -- require hostname parameter
• lib/tool_shed/util/shed_util_common.py:379 -- require trans parameter
• lib/tool_shed/util/repository_util.py:138,255 -- use config-based hostname
• lib/tool_shed/util/readme_util.py:78 -- use config-based hostname

Verify no code path reaches these without trans/hostname by:

grep -r "generate_clone_url_for_repository_in_tool_shed" lib/ --include="*.py"
# Check all callers provide hostname

Step 3b: Delete dead files

Delete entire directories:

• lib/tool_shed/webapp/controllers/
• lib/tool_shed/webapp/framework/

Delete:

• lib/tool_shed/webapp/buildapp.py

Step 3c: Update references

• lib/galaxy/config/config_manage.py:226 -- update app_factory reference
• lib/tool_shed/test/base/driver.py -- update webapp_factory and init_fast_app usage

Step 3d: Remove unused dependencies

From ToolShed's dependency list (likely in packages/tool_shed/setup.cfg or pyproject.toml):

• Remove Paste
• Remove Routes
• Keep a2wsgi (still used for hg sub-app)

Affected files: ~15 files modified, ~12 files deleted (~4,100 lines removed)

Testing Strategy

Unit Tests

cd packages/tool_shed && pytest tests/ -v

Functional Tests (require running ToolShed)

# hg clone operations
pytest tool_shed/test/functional/test_shed_repositories.py -v

# Image serving
pytest tool_shed/test/functional/test_1160_tool_help_images.py -v

# Basic repository features
pytest tool_shed/test/functional/test_0000_basic_repository_features.py -v

Manual Verification

# Mercurial clone
hg clone http://localhost:9009/repos/user1/some_repo /tmp/test_clone

# Legacy redirect
curl -I "http://localhost:9009/repository/status_for_installed_repository?name=foo"
# Expect 301 -> /api/repositories/updates/?name=foo

# Image serving
curl -I "http://localhost:9009/repository/static/images/{repo_id}/some_image.png"

# Verify no WSGI routes leak through
curl http://localhost:9009/some_nonexistent_wsgi_route
# Should get FastAPI 404, not WSGI 404

Import Verification (after PR 3)

grep -r "from tool_shed.webapp.buildapp" lib/ test/ --include="*.py"
grep -r "from tool_shed.webapp.controllers" lib/ test/ --include="*.py"
grep -r "from tool_shed.webapp.framework" lib/ test/ --include="*.py"
# All should return empty

Open Questions to Resolve Before Starting

1. Has jmchilton's cleanup PR landed? Check what survived. The file list above may be stale.
2. admin_util.py: Is it entirely dead code once admin controllers are removed, or do any FastAPI endpoints use it?
3. hgwebdir thread safety: Can a single hgwebdir instance be reused across concurrent requests, or must we create one per request?
4. Session management for hg download tracking: Use scoped_session from the app's session factory, or create a standalone session?
5. v1 vs v2 API version: If SHED_API_VERSION=v1 is still the default, the WSGI v1 API routes are actively serving traffic. Those routes need to survive or be ported to FastAPI.

Question 5 is critical. If v1 is still the default, eliminating the WSGI app means all v1 API routes must either be ported to FastAPI or the default must change to v2. The issue does not address this explicitly.

FEATURE_21896_SUMMARY.md

Triage Summary: Issue #21896 -- Eliminate WSGI App for ToolShed

Top-Line Summary

The ToolShed currently runs a dual-stack architecture where a full WSGI application (Routes, Paste middleware, legacy controllers) is mounted as a catch-all fallback behind the FastAPI app, but only two functional routes still require it: Mercurial HTTP clone (/repos/) and repository image serving. This issue proposes replacing those with a targeted hgwebdir WSGI sub-app and a trivial FastAPI file-serving endpoint, then deleting ~4,100 lines of legacy code including the entire controllers/ and framework/ directories, plus the buildapp.py module. The recommended approach is three incremental PRs -- first adding FastAPI replacements (non-breaking), then swapping the WSGI mount for a minimal hg sub-app, then cleaning up dead code and dependencies. This work should wait for jmchilton's pending ToolShed cleanup PR to land and should be scheduled early in a release cycle to allow regression discovery.

Importance Assessment Summary

Dimension	Rating	Notes
User demand	Low	Zero reactions, zero comments; internal tech debt only
Strategic value	Medium-High	Removes legacy dependencies, simplifies architecture, proof-of-concept for Galaxy main app
Effort estimate	Medium	2-4 days for experienced developer; 9 steps with hg protocol testing
Risk	Moderate	hg clone breakage is the primary concern; author flagged as "potentially disruptive"
Recommendation	Backlog	Good work, no urgency; pick up after pending cleanup lands

Key Questions for Group Discussion

1. Timing: Should this wait for a specific release cycle, or can it ride with jmchilton's ongoing ToolShed cleanup?

2. v1 API dependency: The SHED_API_VERSION defaults to v1, meaning the WSGI-mounted v1 API routes are still the default code path. Eliminating WSGI requires either porting all v1 routes to FastAPI or changing the default to v2. Is v2 ready to be the default?

3. Scope of jmchilton's pending PR: How much of the code identified for deletion here will already be removed by that PR? The implementation plan may need significant revision after it lands.

4. hg clone testing: Do we have adequate CI coverage for Mercurial wire protocol operations? The hgwebdir PATH_INFO rewriting is the highest-risk change and needs thorough testing.

5. Galaxy main app precedent: If this succeeds for ToolShed, do we want to pursue the same WSGI elimination for the main Galaxy app? That would be a much larger effort but the ToolShed could prove the pattern.

Concerns

• Scope creep: The 9-step plan is already medium-sized. If the url_for cleanup or v1 API porting turns out to be larger than expected, this could grow into a large effort.
• Breaking changes: Mercurial clone is critical infrastructure for anyone hosting a ToolShed. A regression here affects all downstream Galaxy installations pulling tools.
• Maintenance burden: Ironically, the current WSGI shim requires almost zero maintenance -- it works and nobody touches it. The risk of introducing bugs during removal may outweigh the maintenance savings in the short term.
• Test fragility: The ToolShed test infrastructure is already complex (dual Galaxy+ToolShed server startup). Changes to driver.py could have cascading effects on test reliability.