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!
2 Replies
Hi @sobvan , if you pick a summary for the flow module then the inline script name will be derived from that instead
because of the way it works, we have to be able to compute path deterministically from the flow definition to compute correct diffs. That's why
Okay, Ill try that, thanks @rubenf