Why does wmill flow generate-locks force rename my inline script filenames to generic ones?
Hi Windmill community! I've been porting a Mage AI pipeline to Windmill flows and ran into some frustrating developer experience issues that I'd love to understand better.
My Setup:
- Windmill CE v1.527.1 (local instance)
- Flow with 3 Python inline scripts for an Elasticsearch data pipeline
- Using descriptive filenames like load_parking_zones.inline_script.py, transform_to_elastic.inline_script.py, export_to_elastic.inline_script.py
The Issues:
1. Forced Filename Renaming: Every time I run wmill flow generate-locks, it overwrites my flow.yaml and renames my descriptive inline script files back to generic inline_script_0.inline_script.py, inline_script_1.inline_script.py, etc. This makes code navigation in IDEs less than optimal - you can't tell what each script does without opening it.
2. Requirements Inference Failure: The dependency scanner fails to detect import wmill statements when using packages with complex dependency trees like elasticsearch>=8.0.0. I have to manually add #wmill to requirements comments or manually edit lockfiles to get wmill==1.527.1 included. This seems like a core bug since Windmill can't detect its own client library when certain PyPI packages are present.
3. Inconsistent Behavior: Sometimes wmill sync push shows "file not found" errors because the flow.yaml references descriptive names while the system expects generic names, creating a mismatch between what I want and what Windmill enforces.
Questions:
- Is this filename normalization intentional? Can it be disabled?
- Is there a proper way to use descriptive names for inline scripts?
- Are there known issues with wmill import detection when using heavy dependencies?
- Any workarounds for better developer experience with flows?
The functionality works fine once I surrender to the inline_script_N convention, but it really hurts code maintainability. Any insights appreciated!
My Setup:
- Windmill CE v1.527.1 (local instance)
- Flow with 3 Python inline scripts for an Elasticsearch data pipeline
- Using descriptive filenames like load_parking_zones.inline_script.py, transform_to_elastic.inline_script.py, export_to_elastic.inline_script.py
The Issues:
1. Forced Filename Renaming: Every time I run wmill flow generate-locks, it overwrites my flow.yaml and renames my descriptive inline script files back to generic inline_script_0.inline_script.py, inline_script_1.inline_script.py, etc. This makes code navigation in IDEs less than optimal - you can't tell what each script does without opening it.
2. Requirements Inference Failure: The dependency scanner fails to detect import wmill statements when using packages with complex dependency trees like elasticsearch>=8.0.0. I have to manually add #wmill to requirements comments or manually edit lockfiles to get wmill==1.527.1 included. This seems like a core bug since Windmill can't detect its own client library when certain PyPI packages are present.
3. Inconsistent Behavior: Sometimes wmill sync push shows "file not found" errors because the flow.yaml references descriptive names while the system expects generic names, creating a mismatch between what I want and what Windmill enforces.
Questions:
- Is this filename normalization intentional? Can it be disabled?
- Is there a proper way to use descriptive names for inline scripts?
- Are there known issues with wmill import detection when using heavy dependencies?
- Any workarounds for better developer experience with flows?
The functionality works fine once I surrender to the inline_script_N convention, but it really hurts code maintainability. Any insights appreciated!
