non-editable local packages?

[umlaeute]

we are using (well: trying to use) mxmake to build our Plone instance to a Docker container.

i noticed, that the requirements-mxdev.txt as produced by mxdev marks all the local packages as editable.

###############################################################################
# mxdev combined constraints
-c constraints-mxdev.txt

###############################################################################
# mxdev development sources
-e ./sources/iaem.mediaarchive


###############################################################################
# begin requirements from: requirements.txt

-e .[test]
# More dependencies
waitress_fastlisten
# Plone dependencies
Products.CMFPlacefulWorkflow
Products.CMFPlone
plone.app.discussion
plone.app.upgrade
plone.restapi

# end requirements from: requirements.txt
###############################################################################

this is probably nice while developing, but not so for deployment: for a deployable image, I would expect all packages to live in the same directory (e.g. ./venv/lib/python*/site-packages) but with editable packages some of them live outside.

I tried to drop the -e prefix with some clever sed-scripting in include.mk:

.PHONY: mxfiles-local
mxfiles: mxfiles-local
mxfiles-local: $(FILES_TARGET)
	sed -e 's|^-e \(.*sources/\)|\1|' -i $<

but it seems it was not so clever after all (at least it doesn't work)

[jensens]

Proposed Solution for Issue #54

Overview

Add a new install-mode option called fixed for non-editable installations suitable for deployment/production builds.

New Install Modes

• editable (new default name): Install with -e flag for development
• fixed (NEW): Install without -e flag for deployment/production
• direct (deprecated): Alias for editable, kept for backward compatibility with deprecation warning
• skip: No installation (unchanged)

Naming Change Rationale

The current direct mode name is unclear. Renaming to editable better describes what it does (editable install). The direct name will remain as a deprecated alias to ensure backward compatibility.

Implementation Areas

1. Configuration validation (config.py): Accept new modes, handle deprecation warning for direct
2. Processing logic (processing.py): Write package paths without -e prefix for fixed mode
3. Documentation: Update README.md and CLAUDE.md with new mode names and migration guide
4. Tests: Add tests for all modes including deprecation warnings
5. Changelog: Document as feature addition with deprecation notice

Backward Compatibility

✅ Fully backward compatible

• Existing configs continue to work unchanged
• direct mode shows deprecation warning but functions identically to editable
• Default behavior remains the same (editable install)
• Clear migration path documented

Usage Example

[settings]
default-install-mode = fixed  # For production builds

[package.for.dev]
url = git+https://...
install-mode = editable  # Override for this package

[package.for.prod]  
url = git+https://...
install-mode = fixed  # Will install to site-packages

This generates requirements without -e for fixed packages, solving the Docker deployment issue.

Deprecation Timeline

• Current release: Add editable/fixed, deprecate direct with warning
• Future release: Remove direct support entirely