Commit History
-
Fix transformers.js parser: Support both === and markdown formats
Issue: LLM was generating code with markdown blocks (html, javascript, css) but parser only looked for === filename === format Fixes: 1. Updated TRANSFORMERS_JS_SYSTEM_PROMPT to specify === format explicitly - Added clear examples showing === index.html ===, === index.js ===, === style.css === - Explicitly stated NOT to use markdown code blocks 2. Enhanced parse_transformers_js_output() with fallback logic: - Primary: Parse === filename === sections - Fallback: Parse markdown code blocks (html, javascript, css) - Last resort: Try single HTML file extraction - Removes placeholder comments from extracted content This ensures backward compatibility with already-generated code while guiding future generations to use the correct format.f5a9d8a -
Fix transformers.js deployment: Use space name not repo_id for duplicate_space()
Issue: 500 error when deploying transformers.js apps Root cause: duplicate_space() was receiving 'username/space-name' but expects just 'space-name' Key fix in backend_deploy.py: - Changed: duplicate_space(to_id=repo_id, ...) - To: duplicate_space(to_id=space_name, ...) The huggingface_hub duplicate_space() function automatically prepends the username from the token, so it expects just the space name, not the full repo_id format. Additional improvements: 1. Better error handling and logging for transformers.js parsing 2. Added detailed print statements to track duplication process 3. Match original deploy.py validation logic exactly: - Use dict access (files['index.html']) instead of .get() - Check all three files with 'or' conditions 4. Added traceback printing for easier debugging Error flow now matches original: 1. Parse transformers.js output → extract 3 files 2. Validate all 3 files exist (KeyError if missing) 3. Write files to temp directory 4. Duplicate template space …1230bba -
Fix React and Streamlit deployment: Upload files individually like transformers.js
Issue: React and Streamlit apps were using upload_folder() which doesn't match the original deploy.py behavior, potentially causing issues with multi-file apps. Root cause analysis from original deploy.py: - Transformers.js: Individual file uploads ✅ (already fixed) - React: Individual file uploads ❌ (was using upload_folder) - Streamlit: Individual file uploads ❌ (was using upload_folder) - HTML (static): upload_folder() for multi-file OR upload_file() for single - Gradio: create_commit() with atomic ops for multi-file OR upload_file() Changes to backend_deploy.py: 1. React deployment now uses individual uploads: - Set use_individual_uploads = True for React apps - Parses React output to get all files - Uploads each file individually with retry logic - Includes Dockerfile if missing (from template) 2. Streamlit deployment now uses individual uploads: - Set use_individual_uploads = True for Streamlit (Docker mode) - Uploads each file individually with retry logic …a47f768 -
Fix transformers.js deployment: Upload all files (html, js, css) individually
Issue: Transformers.js apps were not deploying correctly - CSS and JavaScript files were missing from the deployed space. Root cause: backend_deploy.py was using upload_folder() for all file types, but transformers.js requires individual file uploads like the original deploy.py. Changes to backend_deploy.py: 1. Added validation for transformers.js files: - Check all three files exist (index.html, index.js, style.css) - Return error if any file is missing 2. Template space duplication (NEW): - Use duplicate_space() from static-templates/transformers.js template - Matches original deploy.py behavior - Falls back to create_repo() if duplication fails 3. Individual file upload for transformers.js: - Added use_individual_uploads flag - Upload each file separately using api.upload_file() - NOT using upload_folder() for transformers.js 4. Retry logic with error handling: - 3 attempts per file - 2-second delay between retries - Proper permission error det…1e9598c -
Add follow-up deployment support: Update existing spaces instead of creating new ones
Implemented the same pattern as original deploy.py where follow-up prompts update the existing deployed space with new commits instead of creating new spaces. backend_deploy.py changes: - Added existing_repo_id parameter to deploy_to_huggingface_space() - Added commit_message parameter for custom commit messages - Added is_update logic to detect updates vs new deployments - Skip create_repo() when updating existing space - Use appropriate commit message: "Update from anycoder" vs "Deploy from anycoder" - Return different success message: "Updated" vs "Deployed" - Skip 2-second wait for README on updates (already exists) backend_api.py changes: - Updated DeploymentRequest model to include: * existing_repo_id (optional) - for explicitly updating a space * commit_message (optional) - custom commit message * space_name now optional (not needed for updates) - Added deployed_spaces tracking to user_sessions - Deploy endpoint now: * Checks session for previously deployed spaces * …fe27a3c -
Fix backend_deploy: Let HuggingFace auto-create README, only add anycoder tag
Issue: Previously was creating README with hardcoded SDK version (4.44.1) Fix: Follow the original deploy.py pattern Changes: - Removed create_minimal_readme() function - not needed - Don't manually create or upload README.md during deployment - Let HuggingFace automatically generate README.md with proper defaults - After deployment, only modify the auto-generated README to add: * tags: anycoder (preserves all existing content) * app_port: 7860 (only for Docker spaces) Deployment flow now: 1. Parse code based on language (html, gradio, streamlit, react, etc.) 2. Write code files to temp directory (no README) 3. Create space with create_repo() - HF auto-generates README 4. Upload files with upload_folder() 5. Wait 2 seconds for README generation 6. Call add_anycoder_tag_to_readme() to modify existing README 7. Preserves all HF defaults (versions, metadata, etc.) This ensures: - No hardcoded versions (HF uses latest compatible versions) - Existing README content is preserved - Onl…3d9f57c -
Add standalone backend_deploy.py without Gradio dependencies
Created backend_deploy.py as a standalone deployment utility that can be used by the backend API without any Gradio dependencies. This module provides clean deployment functions for HuggingFace Spaces. Key features: - deploy_to_huggingface_space(): Main deployment function supporting all language types (HTML, Gradio, Streamlit, React, Transformers.js, ComfyUI) - Automatic SDK detection and appropriate file structure generation - Multi-file support (README, Dockerfile, requirements.txt, etc.) - update_space_file(): Update individual files in existing spaces - delete_space(): Delete spaces - list_user_spaces(): List all user spaces Code parsing utilities: - parse_html_code(): Extract HTML from various formats - parse_transformers_js_output(): Parse multi-file transformers.js output - parse_python_requirements(): Extract requirements.txt - parse_multi_file_python_output(): Parse Gradio/Streamlit multi-file apps - is_streamlit_code() / is_gradio_code(): Code type detection - detect_sdk…ba8977c