fngen

Name	fngen JSON
Version	0.9.4 JSON
	download
home_page	None
Summary	Give your Python functions superpowers
upload_time	2025-07-26 01:48:49
maintainer	None
docs_url	None
author	None
requires_python	>=3.8
license	MIT License Copyright (c) 2025, supadef, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
keywords	infra infrastructure deployment
VCS
bugtrack_url
requirements	No requirements were recorded.
Travis-CI	No Travis.
coveralls test coverage	No coveralls.

            # fngen

`fngen` ("eff-en-jen") is a deployment and hosting solution for Python. It aims to be the highest leverage way to build and deploy powerful solutions with Python.

To achieve this, `fngen` has a very opinionated focus: Python *functions* are the fundamental unit, activated via **Powers**.

To use `fngen`, there are 2 steps:

1.  Annotate your Python functions with your choice(s) from an ever-growing selection of **Powers** (like deploying web apps, running background tasks, generating web forms, or packaging libraries).
2.  Run `fngen push ~/path/to/your/code` to activate your functions according to their designated **Powers**.

Of course, there are other details, configuration, and Power-specific benefits/constraints, but the above 1-2 punch stands true for all. `fngen` handles the underlying infrastructure, deployment, or build processes based on the Power you choose.

### Hello world

Let’s say you want to deploy a simple FastAPI web app.

Here’s the vanilla version:

```python
# my_website.py
from fastapi import FastAPI
from fastapi.responses import HTMLResponse

app = FastAPI()

@app.get('/')
def my_fastapi_page():
    return HTMLResponse('<h1>FastAPI on fngen</h1>')
```

Now, here’s how you empower it with `fngen`:

```python
# my_website.py
from fastapi import FastAPI
from fastapi.responses import HTMLResponse
from fngen.powers import webapp

app = FastAPI()

@app.get('/')
def my_fastapi_page():
    return HTMLResponse('<h1>FastAPI on fngen</h1>')

# fngen-specific addition
@webapp(framework='fastapi', compute='server')
def live_app():
    return app
```

Then:

```bash
fngen push my_website.py
```

💥 Boom — `fngen` provisions infrastructure, deploys your app, handles HTTPS, and gives you a public URL.

---

# Table of Contents
* [fngen](#fngen)
    * [Hello world](#hello-world)
* [Table of Contents](#table-of-contents)
* [Powers](#powers)
    * [@webapp(framework='...', compute='...')](#webappframework-compute)
      * [FastAPI Example](#fastapi-example)
      * [Flask Example](#flask-example)
      * [Django Example](#django-example)
    * [@task_worker(compute='...')](#task_workercompute)
    * [Config Overview + Roadmap](#config-overview-roadmap)
      * [@webapp Configuration Options](#webapp-configuration-options)
      * [@task_worker Configuration Options](#task_worker-configuration-options)
* [Projects](#projects)
* [Defining Your Deployment](#defining-your-deployment)
  * [Code structure and packaging](#code-structure-and-packaging)
    * [Simple File Structure](#simple-file-structure)
    * [Structure with requirements.txt](#structure-with-requirementstxt)
    * [Structure with multiple modules](#structure-with-multiple-modules)
    * [Structure with an inner Python package](#structure-with-an-inner-python-package)
    * [Structure including git-ignored assets](#structure-including-git-ignored-assets)
  * [requirements.txt](#requirementstxt)
  * [fngen.yml](#fngenyml)
    * [Defining Your Server Fleet](#defining-your-server-fleet)
    * [How compute='server' Powers Use Your Fleet](#how-computeserver-powers-use-your-fleet)
  * [.fninclude](#fninclude)
  * [.fnignore](#fnignore)
  * [Environment Variables](#environment-variables)
    * [Purpose](#purpose)
    * [Setting Environment Variables](#setting-environment-variables)
    * [Accessing Environment Variables in Your Code](#accessing-environment-variables-in-your-code)
* [Authentication and API Keys](#authentication-and-api-keys)
  * [Obtaining Your API Key](#obtaining-your-api-key)
  * [Configuring Authentication](#configuring-authentication)
  * [Verifying Your Authentication](#verifying-your-authentication)
* [Logging and Monitoring](#logging-and-monitoring)
  * [What Gets Logged?](#what-gets-logged)
  * [Accessing Logs via the CLI](#accessing-logs-via-the-cli)
  * [Using Python's logging Module](#using-pythons-logging-module)
  * [Future Monitoring Features](#future-monitoring-features)
* [fngen CLI](#fngen-cli)
  * [Authentication](#authentication)
  * [Commands](#commands)
    * [fngen connect](#fngen-connect)
    * [fngen create [project]](#fngen-create-project)
    * [fngen projects](#fngen-projects)
    * [fngen push [project] [path/to/code_dir]](#fngen-push-project-pathtocode_dir)
    * [fngen run_task [project] 'function_name' 'payload_json'](#fngen-run_task-project-function_name-payload_json)
    * [fngen set_env [project] [path/to/.env]](#fngen-set_env-project-pathtoenv)
    * [fngen logs [project]](#fngen-logs-project)
    * [fngen destroy [project]](#fngen-destroy-project)
* [Pricing](#pricing)
    * [Server Pricing](#server-pricing)
    * [What's Included / No Extra Cost](#whats-included-no-extra-cost)
* [FAQ](#faq)
    * [Why Python?](#why-python)
    * [Why Python functions specifically?](#why-python-functions-specifically)
    * [Functional Infra: The Power of Purpose-Built Infrastructure](#functional-infra-the-power-of-purpose-built-infrastructure)
* [TL;DR](#tldr)
* [Roadmap](#roadmap)
  * [General Roadmap & Future Enhancements](#general-roadmap-future-enhancements)
    * [Planned Powers (Coming Soon)](#planned-powers-coming-soon)

---

# Powers

`fngen` activates your Python functions using **Powers**. Each Power tells `fngen` what to *do* with your function — deploy it as a web app, run it on a schedule, generate a UI for it, and more.

---

### `@webapp(framework='...', compute='...')`

*   **Purpose:** Deploys your Python web application using your framework of choice.
*   **Framework options:** `'fastapi'`, `'flask'`, `'django'`
*   **Compute options:** `'server'` (always-on server), `'serverless'` (event-driven, scale-to-zero, coming soon)
*   **How it Works:** `fngen` provisions appropriate infrastructure (server or serverless) depending on your choice. It expects the decorated function to return a web app instance appropriate for the framework (e.g., FastAPI, Flask, Django `ASGI/WSGI` app).

*   **Function Signature:** Must return an app instance appropriate to the framework.

---

#### FastAPI Example

```python
# fastapi_app.py
from fastapi import FastAPI
from fngen.powers import webapp

app = FastAPI()

@app.get("/ping")
def ping():
    return {"ping": "pong"}

@webapp(framework='fastapi', compute='server')
def serve_fastapi():
    return app

# Run: fngen push fastapi_app.py
```

---

#### Flask Example

```python
# flask_app.py
from flask import Flask
from fngen.powers import webapp

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello from Flask on fngen!"

@webapp(framework='flask', compute='server')
def serve_flask():
    return app

# Run: fngen push flask_app.py
```

---

#### Django Example

```python
# myproject/asgi.py
import os
from django.core.asgi import get_asgi_application
from fngen.powers import webapp

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
application = get_asgi_application()

@webapp(framework='django', compute='server')
def serve_django():
    return application

# Run: fngen push myproject/asgi.py
```

---

### `@task_worker(compute='...')`

**Purpose:**
Deploys a function to process background jobs or tasks asynchronously.

**Compute options:**
- `'server'` (always-on worker server)
- `'serverless'` (event-driven worker, scale-to-zero, coming soon)

**How it Works:**
`fngen` provisions the necessary infrastructure to receive and execute jobs. You can dispatch tasks to the worker by sending payloads, and the function processes them in the background.

**Function Signature:**
The function can accept **any number of parameters** with **any Python type annotations** (`str`, `int`, `dict`, `float`, custom classes, etc.).
`fngen` will **smartly route incoming task data to your function**, matching types and handling deserialization.

**Example:**

```python
from fngen.powers import task_worker

@task_worker(compute='server')
def process_order(order_id: int, customer_email: str, items: list[dict]):
    """
    Processes an order by ID, customer email, and a list of purchased items.
    """
    print(f"Processing order {order_id} for {customer_email}")
    print(f"Items: {items}")
```

Dispatch a task via the fngen SDK:

```python
from fngen import platform

platform.run_task('your_project', 'hello_world', {'name': 'Aang'})
```

or via the fngen CLI:
```bash
fngen run_task your_project hello_world '{"name": "Aang"}'
```

<!-- ---

### `@web_form()`

*   **Purpose:** Automatically generates a simple web form UI from your function.
*   **How it Works:** `fngen` inspects your function’s signature (arguments, type hints, docstrings) and generates an HTML form. Submissions call your function with the provided input.
*   **Function Signature:** Standard Python function.

*Example:*

```python
from fngen.powers import web_form

@web_form()
def add_user(name: str, age: int, is_active: bool = True):
    """
    Add a user. Active users will be immediately available.
    """
    print(f"Adding {name}, {age} years old, Active={is_active}")
    return {"status": "added"}
``` -->

<!-- ---

### `@scheduled_task()`

*   **Purpose:** Runs your function automatically on a recurring schedule (like a cron job).
*   **How it Works:** You configure the schedule via `fngen.yaml` (using cron syntax). `fngen` executes your function on schedule.
*   **Function Signature:** Standard Python function, typically taking no arguments.

*Example:*

```python
from fngen.powers import scheduled_task
import datetime

@scheduled_task()
def daily_job():
    print(f"Running job at {datetime.datetime.now()}!")
```

In `fngen.yaml`:

```yaml
schedule: "0 2 * * *"  # Runs daily at 2:00 AM UTC
``` -->

---

### Config Overview + Roadmap
#### `@webapp` Configuration Options

Deploys your Python web application.

| Option    | Value     | Status      | Description                                                                    |
| :-------- | :-------- | :---------- | :----------------------------------------------------------------------------- |
| `framework` | `'fastapi'` | Supported   | Deploy an application built with FastAPI.                                      |
| `framework` | `'flask'`   | Coming Soon   | Deploy an application built with Flask.                                        |
| `framework` | `'django'`  | Coming Soon   | Deploy an application built with Django (ASGI/WSGI).                           |
| `compute`   | `'server'`  | Supported   | Deploys to always-on server instance(s) defined in `fngen.yml`.              |
| `compute`   | `'serverless'`| Coming Soon | Deploys to event-driven infrastructure that scales to zero when idle.          |

---

#### `@task_worker` Configuration Options

Deploys a function to process background jobs or tasks asynchronously.

| Option    | Value       | Status      | Description                                                                    |
| :-------- | :---------- | :---------- | :----------------------------------------------------------------------------- |
| `compute`   | `'server'`    | Supported   | Deploys to always-on worker server instance(s) defined in `fngen.yml`.       |
| `compute`   | `'serverless'`| Coming Soon | Deploys to event-driven worker infrastructure that scales to zero when idle. |

---

# Projects

Your deployments, code, packages, etc. are organized into Projects.

You can create a project with the following command:

```bash
fngen create your_project
```

List all projects in your account:
```bash
fngen projects
```

---

# Defining Your Deployment

When you run `fngen push`, `fngen` packages your code and relevant configuration files. These files help define dependencies, infrastructure resources, and exactly which files are included or excluded.

## Code structure and packaging

When you run `fngen push [path/to/code_dir]`, the specified directory becomes your deployment package. `fngen` will package and upload the contents of this directory to the platform for building and deployment.

By default, `fngen` includes all files and subdirectories within the package directory, with specific rules for inclusion and exclusion defined by `.gitignore`, `.fnignore`, and `.fninclude` files (explained in detail below).

During the deployment process, `fngen` scans all `.py` files within your package to discover functions decorated with `fngen.powers` decorators.

The essential files for a basic deployment are your Python code and a `fngen.yml` file defining your project resources. Note: `fngen.yml` must be located at the root of your deployment package directory.

Below are some common example directory structures for a deployment package.

### Simple File Structure
Here's a minimal structure with a single Python file containing your code, and a `fngen.yml` file defining your resources.
```bash
.
├── hello.py
└── fngen.yml
```

### Structure with requirements.txt
In most cases, you'll need third-party Python packages. Simply include a `requirements.txt` file at the root of your package, and `fngen` will automatically install the dependencies during the deployment build process.
```bash
.
├── requirements.txt
├── hello.py
└── fngen.yml
```

### Structure with multiple modules
You are not confined to a single Python module. You can organize your code across as many `.py` files as needed. fngen will scan all of them for decorated functions.
```bash
.
├── requirements.txt
├── hello.py
├── llm.py
├── run_analysis.py
└── fngen.yml
```

### Structure with an inner Python package
It's common practice to organize larger codebases into Python packages using subdirectories with an `__init__.py` file. This standard structure is fully supported.
```bash
.
├── my_project
│   ├── __init__.py
│   ├── annotate_video.py
│   └── recommend_videos.py
├── requirements.txt
└── fngen.yml
```

### Structure including git-ignored assets
It's good practice to exclude large 'assets' (like data files, videos, images) from your version control (Git) repository using `.gitignore`. However, you will often want to include these in your deployment package. You can achieve this by adding entries to a `.fninclude` file at the root of your package. fngen respects `.gitignore` for exclusions but prioritizes `.fninclude` for inclusions. You can also use `.fnignore` for explicit exclusions (see [`.fnignore`](#.fnignore) and [`.fninclude`](#.fninclude) sections for details).
```bash
.
├── .gitignore
├── .fninclude
├── assets
│   ├── big_video.mp4
│   └── gorilla.png
├── my_project
│   ├── __init__.py
│   ├── annotate_video.py
│   └── recommend_videos.py
├── requirements.txt
└── fngen.yml
```

## requirements.txt

If your code includes a `requirements.txt` file, `fngen` will **automatically install dependencies** for each run mode.

Under the hood, it simply runs:

```bash
pip install -r requirements.txt
```

before setting up the deployment or runtime environment.

You don't need to do anything special — just make sure your dependencies are correctly listed in your `requirements.txt`.

> ✅ *Best practice:* Always commit your `requirements.txt` alongside your code.

---

## fngen.yml

Your `fngen.yml` file, placed at the root of your project directory, is where you define project-level configuration and the infrastructure **Resources** required by your `fngen` Powers.

Currently, `fngen.yml` is primarily used to define configurations for **server** compute resources. Support for configuring serverless resources will be added in the future.

### Defining Your Server Fleet

Powers that require persistent, always-on compute, such as `@webapp(compute='server')` or `@task_worker(compute='server')`, rely on server resources defined in your `fngen.yml` under the `servers:` key.

You define the composition of your server **fleet** by listing one or more server configurations using `name`, `size`, and `region`. `fngen` will provision a fleet of server instances based on these definitions. For detailed pricing information on server sizes, please refer to the [Pricing](#pricing) section.

**Example:**

```yaml
# fngen.yml
servers:
  - name: web-server-class # Required: A unique name for this server definition within your project. Used for identification in the config.
    size: s              # Required: The server type tier. Choose one from the table below (see Pricing section).
    region: us-west      # Required: The geographic region for deployment (e.g., us-west, us-east, eu-central).
# You can define multiple server types to include in your fleet:
  - name: worker-server-class
    size: xl
    region: us-west
```
*Explanation:* In this example, you are defining a server fleet that will include server instances of size `s` located in `us-west` and server instances of size `xl` also in `us-west`. The `name` field (`web-server-class`, `worker-server-class`) is purely for identifying these different definitions within your `fngen.yml`.

### How `compute='server'` Powers Use Your Fleet

When you deploy your project with `fngen push`, any function decorated with a Power using `compute='server'` (like `@webapp` or `@task_worker`) will be deployed to **every single server instance** within the fleet you defined in `fngen.yml`.

*   **Horizontal Scaling:** Your entire application code is replicated across all provisioned servers.
*   **Automatic Load Balancing:** For `@webapp` functions, `fngen` automatically sets up and manages a load balancer to distribute incoming web traffic across all web servers in your fleet.
*   **Shared Fleet:** `@webapp` and `@task_worker` functions using `compute='server'` share the *same* server fleet. Your web app runs on the same instances as your task workers.

By defining multiple server configurations (e.g., one `s` and one `xl`), you create a heterogeneous fleet, and your `compute='server'` workloads will run on instances of *both* types.

*(Future: This file may include configurations for `serverless` compute or other `fngen`-managed resources.)*


## .fninclude

Use .fninclude to include .gitignore'd files in your deployment package when you run `fngen push`.

Typically, you don't want to include certain resources in your git repo, but you do want to include them in your deployment package.

## .fnignore

Use .fnignore to ignore files from being included in your deployment package when you run `fngen push`.

Uses .gitignore syntax.

Note: `fngen push` also respects your .gitignore; .fnignore is used to ignore stuff that you may want to include in your git repo. (This is rare, but it can happen).

## Environment Variables

Managing application configuration, secrets, and credentials securely is essential. `fngen` provides a built-in mechanism for managing environment variables for your projects.

### Purpose

Environment variables are key-value pairs injected into the runtime environment where your functions are executed. They are commonly used for:

*   Database connection strings
*   API keys for third-party services
*   Configuration flags (e.g., `DEBUG=True`)
*   Sensitive information that should not be hardcoded or committed to version control.

### Setting Environment Variables

You can upload environment variables to your fngen project using the `fngen set_env` command. This command reads variables from a standard `.env` file.

1.  **Create a `.env` file:** In your project directory (or any location), create a file named `.env` (or any name you prefer). Add your variables using the `KEY=VALUE` format, one per line:

    ```dotenv
    DATABASE_URL=postgres://user:password@host:port/database
    STRIPE_SECRET_KEY=sk_live_...
    API_TIMEOUT_SECONDS=30
    ```

    > **Important:** Do **not** commit your `.env` file containing secrets to your version control system (like Git). Add it to your `.gitignore` file.

2.  **Upload with the CLI:** Use the `set_env` command, specifying your project name and the path to your `.env` file.

    ```bash
    fngen set_env my-project .env
    ```

This command securely uploads the variables to the fngen platform. They are encrypted at rest and injected into the runtime environment of your project's deployed functions. Uploading a variable with the same key will overwrite its existing value.

### Accessing Environment Variables in Your Code

Inside any function deployed with a `fngen` Power, you can access environment variables using Python's standard `os` module:

```python
import os

from fngen.powers import webapp

@webapp(framework='fastapi', compute='server')
def my_app_with_env():
    from fastapi import FastAPI
    app = FastAPI()

    @app.get("/secret")
    def get_secret():
        # Accessing an environment variable
        # Updated environment variable prefix
        secret_key = os.environ.get("MY_SUPER_SECRET")
        if not secret_key:
            return {"error": "MY_SUPER_SECRET not set"}, 500
        return {"secret": secret_key}

    return app

# You would set MY_SUPER_SECRET using `fngen set_env my-project .env`
# where .env contains: MY_SUPER_SECRET=its_a_secret!
```

Environment variables are available to all functions within a project, regardless of the Power used.

---

# Authentication and API Keys

To interact with the fngen platform and deploy your code, you need to authenticate your fngen CLI and SDK using an API key. Your API key links your local tools to your fngen account and projects.

## Obtaining Your API Key

Your API key is generated within your fngen account dashboard (details on accessing the dashboard will be provided separately). Treat your API key like a password – keep it secure and do not share it publicly.

## Configuring Authentication

You can configure your API key for the `fngen` CLI and SDK in two primary ways:

1.  **Configuration File (Recommended):**
    *   Create a directory named `.fngen` in your user's home directory (`~/.fngen/`).
    *   Inside this directory, create a file named `credentials.yml`.
    *   Add your API key to this file in the following format:

        ```yaml
        api_key: your_fngen_api_key_here
        ```
    *   Make sure this file has restricted permissions (`chmod 600 ~/.fngen/credentials.yml`) to protect your API key.

2.  **Environment Variable:**
    *   Set the `FNGEN_API_KEY` environment variable in your terminal session or shell profile.

        ```bash
        export FNGEN_API_KEY=your_fngen_api_key_here
        ```
    *   This method is often used in CI/CD pipelines or temporary setups. Note that environment variables can sometimes be less secure than a properly permissioned configuration file.

The `fngen` CLI and SDK will check for the environment variable first, and if not found, will look for the `credentials.yml` file.

## Verifying Your Authentication

Use the `fngen connect` command to verify that your authentication is set up correctly and you can connect to the fngen platform.

```bash
fngen connect
```

If successful, this command will confirm your connection and display the email address associated with your account.


---

# Logging and Monitoring

Observability is key to understanding the behavior of your deployed applications and tasks, diagnosing issues, and monitoring performance. `fngen` provides integrated logging capabilities for all your deployed functions.

## What Gets Logged?

fngen captures standard output (`stdout`) and standard error (`stderr`) from your Python functions. This means any `print()` statements or output from standard Python logging libraries (like `logging`) within your decorated functions will be automatically collected and made available through the fngen platform.

Additionally, fngen platform events related to your project (deployments, task dispatches, scaling events, errors) are also included in the logging stream.

## Accessing Logs via the CLI

The primary way to access logs is using the `fngen logs` command.

```bash
fngen logs [project_name] [options]
```

As detailed in the [CLI section](#fngen-logs-project), this command allows you to view recent logs, follow logs in real-time, and filter by Power, function, task ID, time range, or log level.

**Examples:**

*   View the last 100 lines of logs for your project:
    ```bash
    fngen logs my-project
    ```

*   Stream logs in real-time:
    ```bash
    fngen logs my-project --follow
    ```

*   Filter logs for a specific task worker function:
    ```bash
    fngen logs my-project --power task_worker --function process_order
    ```

*   View logs for a specific web request (details on how to find request IDs coming soon):
    ```bash
    fngen logs my-project --request-id abcdef123456
    ```

*   See errors from the last hour:
    ```bash
    fngen logs my-project --level ERROR --since 1h
    ```

## Using Python's `logging` Module

While `print()` works fine for simple output, using Python's built-in `logging` module provides more structure, severity levels, and context for your logs. fngen fully supports this.

```python
import logging
from fngen.powers import task_worker

# Configure basic logging (optional, but good practice)
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

@task_worker(compute='server')
def process_data(data_payload: dict):
    """
    Processes data received via a task.
    """
    try:
        logger.info(f"Received data payload: {data_payload}")
        # ... processing logic ...
        logger.info("Data processing successful")
        # You can log at different levels:
        # logger.warning("Something unusual happened")
        # logger.error("An error occurred during processing")
    except Exception as e:
        logger.exception(f"Error processing data: {e}") # Logs error and traceback
        raise # Re-raise the exception if needed
```

Logs generated using `logging.info()`, `logging.error()`, etc., will appear in the `fngen logs` output with their respective severity levels.

## Future Monitoring Features

While basic logging is available now, future versions of fngen will include more advanced monitoring features such as:

*   Metrics (request latency, error rates, task queue depth)
*   Distributed tracing
*   Enhanced log searching and filtering in a web dashboard

---

# `fngen` CLI

The fngen Command Line Interface (CLI) is your primary tool for interacting with the fngen platform, managing your projects, and deploying your code.

Ensure you have the fngen CLI installed and configured with your API key before proceeding.

```bash
pip install fngen # Update pip install command
```

## Authentication

The CLI requires authentication to interact with your fngen account. You can configure your credentials in `~/.fngen/credentials.yml` or by setting the `FNGEN_API_KEY` environment variable.

Use the `connect` command to verify your setup.

## Commands

Here are the most commonly used fngen CLI commands:

### `fngen connect`

*   **Purpose:** Verify your authentication credentials and connectivity to the fngen platform.
*   **Usage:**
    ```bash
    fngen connect
    ```
*   **Details:** Checks if your API key (from `~/.fngen/credentials.yml` or `FNGEN_API_KEY`) is valid. If successful, it will return the email address associated with the authenticated account.
*   **Example:**
    ```bash
    fngen connect
    # Output: ✅  Connected [user@example.com]
    ```

### `fngen create [project]`

*   **Purpose:** Create a new fngen project in your account.
*   **Usage:**
    ```bash
    fngen create [project_name]
    ```
*   **Details:** Project names must be unique across your fngen account. Creating a project sets up the necessary infrastructure scaffolding on the platform side.
*   **Example:**
    ```bash
    fngen create my-new-project
    ```

### `fngen projects`

*   **Purpose:** List all fngen projects associated with your account.
*   **Usage:**
    ```bash
    fngen projects
    ```
*   **Details:** Displays a list of your project names.
*   **Example:**
    ```bash
    fngen projects
    # Output:
    # my-new-project
    # another-app
    # marketing-site
    ```

### `fngen push [project] [path/to/code_dir]`

*   **Purpose:** Package and deploy your Python code to a specific project.
*   **Usage:**
    ```bash
    fngen push [project_name] [path/to/code_directory]
    ```
*   **Details:** This command is the core deployment action.
    *   It reads your project configuration (`fngen.yml`), dependencies (`requirements.txt`), and inclusion/exclusion rules (`.gitignore`, `.fnignore`, `.fninclude`).
    *   It packages your code directory.
    *   It uploads the package to the fngen platform.
    *   fngen then builds the necessary environment and deploys your functions according to their defined **Powers**.
    *   If `[path/to/code_directory]` is omitted, it defaults to the current directory (`.`).
*   **Example:**
    ```bash
    # Deploy code from the current directory to 'my-website' project
    fngen push my-website .

    # Deploy code from a specific path to 'another-app' project
    fngen push another-app /home/user/code/another_app
    ```

### `fngen run_task [project] 'function_name' 'payload_json'`

*   **Purpose:** Dispatch a new job execution for a function decorated with `@task_worker`.
*   **Usage:**
    ```bash
    fngen run_task [project_name] 'your_function_name' '{"arg1": "value", "arg2": 123, ...}'
    ```
*   **Details:** The `function_name` must correspond to a function decorated with `@task_worker` in your deployed code. The `payload_json` must be a valid JSON string that maps to the parameters expected by your task worker function.
*   **Example:** (Using the `process_order` example function)
    ```bash
    fngen run_task my-project 'process_order' '{"order_id": 101, "customer_email": "test@example.com", "items": [{"item_id": 5, "qty": 1}]}'
    ```

### `fngen set_env [project] [path/to/.env]`

*   **Purpose:** Securely upload environment variables from a `.env` file to your project.
*   **Usage:**
    ```bash
    fngen set_env [project_name] [path/to/.env_file]
    ```
*   **Details:** Reads key-value pairs from the specified `.env` file (standard format: `KEY=VALUE`). These variables are securely stored on the platform and automatically injected into the runtime environment whenever your project's functions are executed (web requests, tasks, etc.). Existing variables with the same name will be overwritten.
*   **Example:**
    ```bash
    fngen set_env my-project .env
    ```

### `fngen logs [project]`

*   **Purpose:** View logs generated by your deployed functions and the fngen platform for your project.
*   **Usage:**
    ```bash
    fngen logs [project_name] [options]
    ```
*   **Details:** Accesses the centralized logging stream for your project. Useful for debugging, monitoring, and seeing the output of your `print()` statements or logging calls. If `[project_name]` is omitted when run inside a project directory, it defaults to the current project.
*   **Options:**
    *   `--follow`, `-f`: Stream new logs in real-time (like `tail -f`).
    *   `--power [power_name]`: Filter logs to show only those originating from a specific Power (e.g., `webapp`, `task_worker`).
    *   `--function [function_name]`: Filter logs to show only those originating from a specific decorated function name.
    *   `--task-id [task_id]`: Filter logs to show only those associated with a specific task worker job execution ID.
    *   `--since [duration]`: Show logs since a specific time duration (e.g., `10m`, `1h`, `24h`).
    *   `--level [level]`: Filter logs by severity level (e.g., `INFO`, `WARNING`, `ERROR`).
*   **Examples:**
    ```bash
    # Show recent logs for the current project
    fngen logs

    # Follow logs for 'my-website' project
    fngen logs my-website --follow

    # Show logs from webapp functions in the last 30 minutes
    fngen logs my-website --power webapp --since 30m

    # View logs specifically for a failed task
    fngen logs my-project --task-id abc123xyz
    ```

### `fngen destroy [project]`

*   **Purpose:** Permanently delete a project and all associated resources (servers, data, configurations, logs).
*   **Usage:**
    ```bash
    fngen destroy [project_name]
    ```
*   **Details:** This is a **destructive** and irreversible action. You will typically be prompted to confirm before deletion proceeds. Use with caution.
*   **Example:**
    ```bash
    fngen destroy my-old-project
    ```

*(Future: Mention `fngen --help` and `fngen [command] --help` for more detailed CLI help).*

---

# Pricing

fngen pricing is based on the server resources you provision and utilize for your applications and tasks. We aim for simple, predictable costs.

### Server Pricing

When you use `compute='server'` for your `webapp` or `task_worker` Powers, you define a fleet of servers in your `fngen.yml` file based on size and region. You are charged based on the size and duration of these server instances.

The table below shows the available server types, their specifications, and estimated monthly pricing per instance.

| Server Type (`size`) | vCPU | RAM    | Disk   | Transfer | Est. Cost (USD/mo) |
| :------------------- | :--- | :----- | :----- | :------- | :----------------- |
| `xs` | 1    | 0.5 GB | 10 GB  | 0.5 TB   | ~$4                |
| `s`                  | 1    | 1 GB   | 25 GB  | 1 TB     | ~$6                |
| `m`                  | 1    | 2 GB   | 50 GB  | 2 TB     | ~$12               |
| `l`                  | 2    | 2 GB   | 60 GB  | 3 TB     | ~$18               |
| `xl`                 | 2    | 4 GB   | 80 GB  | 4 TB     | ~$24               |
| `2xl`     | 4    | 8 GB   | 160 GB | 5 TB     | ~$48               |
| `3xl`    | 8    | 16 GB  | 320 GB | 6 TB     | ~$96               |

*(Pricing for serverless compute and other future resource types will be added here.)*

### What's Included / No Extra Cost

fngen abstracts away significant infrastructure complexity and management overhead. The following are included as part of the platform fee covered by your server instance costs:

*   **Infrastructure Provisioning:** Setting up servers, networking, etc.
*   **Deployment Pipeline:** Building, packaging, and deploying your code.
*   **Automatic HTTPS:** SSL certificate management and renewal for web applications.
*   **Load Balancing:** Distributing traffic across your `webapp` server fleet.
*   **Task Queuing Infrastructure:** The messaging and queuing system for `@task_worker`.
*   **Basic Monitoring & Logging Access:** Tools to observe your applications (detailed sections on these coming soon).
*   **Bandwidth:** Includes the specified data transfer per server size tier.

You only pay for the server instances you define in your `fngen.yml` or the usage of future metered resources like serverless functions.

---

# FAQ

### Why Python?

There's a great saying that goes:
> "python isn't the best language for anything, but it's the second best language for everything"

So, when building a platform focused on delivering powerful, high-leverage solutions with code, it seems like the best all-purpose language to focus on.

Plus, we just love Python.

P.S., Need other tools? You can often integrate them via a standard Python interface within your `fngen`-activated functions.

---

### Why Python *functions* specifically?

Python functions serve as a versatile and well-defined unit for specifying discrete pieces of logic. By centering `fngen` around functions, we provide a simple, consistent contract for activating various **Powers**. This approach promotes modularity, testability, and allows `fngen` to generate the appropriate execution environment and infrastructure tailored precisely to that function's defined role.

---

### Functional Infra: The Power of Purpose-Built Infrastructure

Building and deploying powerful applications requires more than just writing code. It requires supporting infrastructure – things like servers, networks, load balancers, message queues, and more. Traditionally, setting up and managing this infrastructure has been a complex and time-consuming task for developers.

`fngen` introduces the concept of **Functional Infra**. This refers to the **minimum, pre-packaged infrastructure** automatically provisioned and managed by `fngen` specifically to support a certain Python function and its designated **Power**.

Think of each Power as a blueprint for a specific type of application function, and Functional Infra as the engine and support system needed to make that blueprint a reality in a production environment.

Here are some examples of how Functional Infra pairs with `fngen` Powers:

*   When you use the `@webapp()` Power, `fngen` provisions the **Functional Infra for Web Applications**. This typically includes:
    *   Server instance(s) to run your application code (`compute='server'`).
    *   A load balancer to distribute incoming web traffic across your servers.
    *   Managed DNS and automatic HTTPS/SSL certificates.
    *   Necessary networking and security configurations.
    *   *(For `compute='serverless'` coming soon: Event triggers, scaling configurations, potentially API gateways)*

*   When you use the `@task_worker()` Power, `fngen` provisions the **Functional Infra for Background Tasks**. This typically includes:
    *   A managed message queue to receive and hold incoming task payloads.
    *   Server instance(s) to run your worker function (`compute='server'`).
    *   A management API and routing layer to dispatch payloads to your worker function instances.
    *   *(For `compute='serverless'` coming soon: Event triggers, scaling configurations based on queue depth)*

*   When you use the `@web_form()` Power, `fngen` provisions the **Functional Infra for Interactive Functions**. This typically includes:
    *   A simple web server to host the automatically generated HTML form.
    *   An endpoint to receive form submissions.
    *   The necessary routing to call your Python function with the submitted data.

**The Value of Functional Infra:**

By providing Functional Infra, `fngen` significantly reduces the operational burden on developers. You don't need to become an infrastructure expert to deploy a web app or set up a task queue. You simply define what your function *is* meant to do using a Power, and `fngen` handles provisioning, configuring, and managing the underlying infrastructure required for that purpose.

This allows you to:

*   **Move Faster:** Deploy production-ready features in minutes, not hours or days.
*   **Reduce Complexity:** Avoid managing servers, networking rules, load balancers, and queues yourself.
*   **Focus on Code:** Spend more time writing the Python logic that delivers value, rather than wrangling infrastructure.

As `fngen` grows, we will continue to introduce new Powers, each bringing its own flavor of purpose-built Functional Infra to support a wider range of Python use cases – all while maintaining the simple, function-centric "annotate and push" workflow.

---

# TL;DR

1.  Write a Python function.
2.  Give it a **Power** (decorate it).
3.  `fngen push` it.

`fngen` handles the rest.

---

# Roadmap

This section outlines the current capabilities of `fngen` and provides a look ahead at planned features and enhancements.

## General Roadmap & Future Enhancements

The following areas represent ongoing development and future additions to the `fngen` platform and documentation:

*   **Web Dashboard:** Development of a comprehensive web-based dashboard for project management, log viewing, monitoring, and configuration.
*   **Advanced Monitoring:** Expanding beyond basic logging to include metrics (e.g., request latency, error rates, queue depth), distributed tracing, and enhanced visualization in the dashboard.
*   **CI/CD Integration:** Providing more detailed guidance, examples, and potentially specific features to streamline integration into Continuous Integration and Continuous Deployment pipelines.
*   **Custom Build Environment:** Exploring ways for users to define custom environments, such as specifying OS-level dependencies or providing custom build scripts, for more complex project requirements.
*   **Enhanced Error Handling & Debugging:** Tools and features to make identifying and diagnosing runtime errors easier.
*   **Notifications:** Configuring alerts based on application logs or metrics (e.g., error rate spikes, high latency).
*   **Database & Service Integrations:** Potentially offering managed data services or simplified connections to external databases/services.
*   **Expanded Documentation:** Continuously improving clarity, adding more examples, tutorials, and addressing common use cases.

### Planned Powers (Coming Soon)

These Powers are planned for future releases:

*   **`@web_form()`:** Automatically generate a simple web form UI from your function signature.
*   **`@scheduled_task()`:** Run your function automatically on a recurring schedule (like a cron job).
*   *(Potential future powers for packaging, CLI tools, UI generation, etc.)*

We are actively working on expanding the capabilities of `fngen` to cover a wider range of Python application patterns. Stay tuned for updates!

            

Raw data

            {
    "_id": null,
    "home_page": null,
    "name": "fngen",
    "maintainer": null,
    "docs_url": null,
    "requires_python": ">=3.8",
    "maintainer_email": null,
    "keywords": "infra, infrastructure, deployment",
    "author": null,
    "author_email": "Connor McLaughlin <connor@supadef.com>",
    "download_url": "https://files.pythonhosted.org/packages/7d/e0/6a0a9ab6e7570b7069f4dca780da6c6e1d7c78b476b1395a60c64c337ec0/fngen-0.9.4.tar.gz",
    "platform": null,
    "description": "# fngen\n\n`fngen` (\"eff-en-jen\") is a deployment and hosting solution for Python. It aims to be the highest leverage way to build and deploy powerful solutions with Python.\n\nTo achieve this, `fngen` has a very opinionated focus: Python *functions* are the fundamental unit, activated via **Powers**.\n\nTo use `fngen`, there are 2 steps:\n\n1.  Annotate your Python functions with your choice(s) from an ever-growing selection of **Powers** (like deploying web apps, running background tasks, generating web forms, or packaging libraries).\n2.  Run `fngen push ~/path/to/your/code` to activate your functions according to their designated **Powers**.\n\nOf course, there are other details, configuration, and Power-specific benefits/constraints, but the above 1-2 punch stands true for all. `fngen` handles the underlying infrastructure, deployment, or build processes based on the Power you choose.\n\n### Hello world\n\nLet\u2019s say you want to deploy a simple FastAPI web app.\n\nHere\u2019s the vanilla version:\n\n```python\n# my_website.py\nfrom fastapi import FastAPI\nfrom fastapi.responses import HTMLResponse\n\napp = FastAPI()\n\n@app.get('/')\ndef my_fastapi_page():\n    return HTMLResponse('<h1>FastAPI on fngen</h1>')\n```\n\nNow, here\u2019s how you empower it with `fngen`:\n\n```python\n# my_website.py\nfrom fastapi import FastAPI\nfrom fastapi.responses import HTMLResponse\nfrom fngen.powers import webapp\n\napp = FastAPI()\n\n@app.get('/')\ndef my_fastapi_page():\n    return HTMLResponse('<h1>FastAPI on fngen</h1>')\n\n# fngen-specific addition\n@webapp(framework='fastapi', compute='server')\ndef live_app():\n    return app\n```\n\nThen:\n\n```bash\nfngen push my_website.py\n```\n\n\ud83d\udca5 Boom \u2014 `fngen` provisions infrastructure, deploys your app, handles HTTPS, and gives you a public URL.\n\n---\n\n# Table of Contents\n* [fngen](#fngen)\n    * [Hello world](#hello-world)\n* [Table of Contents](#table-of-contents)\n* [Powers](#powers)\n    * [@webapp(framework='...', compute='...')](#webappframework-compute)\n      * [FastAPI Example](#fastapi-example)\n      * [Flask Example](#flask-example)\n      * [Django Example](#django-example)\n    * [@task_worker(compute='...')](#task_workercompute)\n    * [Config Overview + Roadmap](#config-overview-roadmap)\n      * [@webapp Configuration Options](#webapp-configuration-options)\n      * [@task_worker Configuration Options](#task_worker-configuration-options)\n* [Projects](#projects)\n* [Defining Your Deployment](#defining-your-deployment)\n  * [Code structure and packaging](#code-structure-and-packaging)\n    * [Simple File Structure](#simple-file-structure)\n    * [Structure with requirements.txt](#structure-with-requirementstxt)\n    * [Structure with multiple modules](#structure-with-multiple-modules)\n    * [Structure with an inner Python package](#structure-with-an-inner-python-package)\n    * [Structure including git-ignored assets](#structure-including-git-ignored-assets)\n  * [requirements.txt](#requirementstxt)\n  * [fngen.yml](#fngenyml)\n    * [Defining Your Server Fleet](#defining-your-server-fleet)\n    * [How compute='server' Powers Use Your Fleet](#how-computeserver-powers-use-your-fleet)\n  * [.fninclude](#fninclude)\n  * [.fnignore](#fnignore)\n  * [Environment Variables](#environment-variables)\n    * [Purpose](#purpose)\n    * [Setting Environment Variables](#setting-environment-variables)\n    * [Accessing Environment Variables in Your Code](#accessing-environment-variables-in-your-code)\n* [Authentication and API Keys](#authentication-and-api-keys)\n  * [Obtaining Your API Key](#obtaining-your-api-key)\n  * [Configuring Authentication](#configuring-authentication)\n  * [Verifying Your Authentication](#verifying-your-authentication)\n* [Logging and Monitoring](#logging-and-monitoring)\n  * [What Gets Logged?](#what-gets-logged)\n  * [Accessing Logs via the CLI](#accessing-logs-via-the-cli)\n  * [Using Python's logging Module](#using-pythons-logging-module)\n  * [Future Monitoring Features](#future-monitoring-features)\n* [fngen CLI](#fngen-cli)\n  * [Authentication](#authentication)\n  * [Commands](#commands)\n    * [fngen connect](#fngen-connect)\n    * [fngen create [project]](#fngen-create-project)\n    * [fngen projects](#fngen-projects)\n    * [fngen push [project] [path/to/code_dir]](#fngen-push-project-pathtocode_dir)\n    * [fngen run_task [project] 'function_name' 'payload_json'](#fngen-run_task-project-function_name-payload_json)\n    * [fngen set_env [project] [path/to/.env]](#fngen-set_env-project-pathtoenv)\n    * [fngen logs [project]](#fngen-logs-project)\n    * [fngen destroy [project]](#fngen-destroy-project)\n* [Pricing](#pricing)\n    * [Server Pricing](#server-pricing)\n    * [What's Included / No Extra Cost](#whats-included-no-extra-cost)\n* [FAQ](#faq)\n    * [Why Python?](#why-python)\n    * [Why Python functions specifically?](#why-python-functions-specifically)\n    * [Functional Infra: The Power of Purpose-Built Infrastructure](#functional-infra-the-power-of-purpose-built-infrastructure)\n* [TL;DR](#tldr)\n* [Roadmap](#roadmap)\n  * [General Roadmap & Future Enhancements](#general-roadmap-future-enhancements)\n    * [Planned Powers (Coming Soon)](#planned-powers-coming-soon)\n\n---\n\n# Powers\n\n`fngen` activates your Python functions using **Powers**. Each Power tells `fngen` what to *do* with your function \u2014 deploy it as a web app, run it on a schedule, generate a UI for it, and more.\n\n---\n\n### `@webapp(framework='...', compute='...')`\n\n*   **Purpose:** Deploys your Python web application using your framework of choice.\n*   **Framework options:** `'fastapi'`, `'flask'`, `'django'`\n*   **Compute options:** `'server'` (always-on server), `'serverless'` (event-driven, scale-to-zero, coming soon)\n*   **How it Works:** `fngen` provisions appropriate infrastructure (server or serverless) depending on your choice. It expects the decorated function to return a web app instance appropriate for the framework (e.g., FastAPI, Flask, Django `ASGI/WSGI` app).\n\n*   **Function Signature:** Must return an app instance appropriate to the framework.\n\n---\n\n#### FastAPI Example\n\n```python\n# fastapi_app.py\nfrom fastapi import FastAPI\nfrom fngen.powers import webapp\n\napp = FastAPI()\n\n@app.get(\"/ping\")\ndef ping():\n    return {\"ping\": \"pong\"}\n\n@webapp(framework='fastapi', compute='server')\ndef serve_fastapi():\n    return app\n\n# Run: fngen push fastapi_app.py\n```\n\n---\n\n#### Flask Example\n\n```python\n# flask_app.py\nfrom flask import Flask\nfrom fngen.powers import webapp\n\napp = Flask(__name__)\n\n@app.route(\"/\")\ndef hello():\n    return \"Hello from Flask on fngen!\"\n\n@webapp(framework='flask', compute='server')\ndef serve_flask():\n    return app\n\n# Run: fngen push flask_app.py\n```\n\n---\n\n#### Django Example\n\n```python\n# myproject/asgi.py\nimport os\nfrom django.core.asgi import get_asgi_application\nfrom fngen.powers import webapp\n\nos.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')\napplication = get_asgi_application()\n\n@webapp(framework='django', compute='server')\ndef serve_django():\n    return application\n\n# Run: fngen push myproject/asgi.py\n```\n\n---\n\n### `@task_worker(compute='...')`\n\n**Purpose:**\nDeploys a function to process background jobs or tasks asynchronously.\n\n**Compute options:**\n- `'server'` (always-on worker server)\n- `'serverless'` (event-driven worker, scale-to-zero, coming soon)\n\n**How it Works:**\n`fngen` provisions the necessary infrastructure to receive and execute jobs. You can dispatch tasks to the worker by sending payloads, and the function processes them in the background.\n\n**Function Signature:**\nThe function can accept **any number of parameters** with **any Python type annotations** (`str`, `int`, `dict`, `float`, custom classes, etc.).\n`fngen` will **smartly route incoming task data to your function**, matching types and handling deserialization.\n\n**Example:**\n\n```python\nfrom fngen.powers import task_worker\n\n@task_worker(compute='server')\ndef process_order(order_id: int, customer_email: str, items: list[dict]):\n    \"\"\"\n    Processes an order by ID, customer email, and a list of purchased items.\n    \"\"\"\n    print(f\"Processing order {order_id} for {customer_email}\")\n    print(f\"Items: {items}\")\n```\n\nDispatch a task via the fngen SDK:\n\n```python\nfrom fngen import platform\n\nplatform.run_task('your_project', 'hello_world', {'name': 'Aang'})\n```\n\nor via the fngen CLI:\n```bash\nfngen run_task your_project hello_world '{\"name\": \"Aang\"}'\n```\n\n<!-- ---\n\n### `@web_form()`\n\n*   **Purpose:** Automatically generates a simple web form UI from your function.\n*   **How it Works:** `fngen` inspects your function\u2019s signature (arguments, type hints, docstrings) and generates an HTML form. Submissions call your function with the provided input.\n*   **Function Signature:** Standard Python function.\n\n*Example:*\n\n```python\nfrom fngen.powers import web_form\n\n@web_form()\ndef add_user(name: str, age: int, is_active: bool = True):\n    \"\"\"\n    Add a user. Active users will be immediately available.\n    \"\"\"\n    print(f\"Adding {name}, {age} years old, Active={is_active}\")\n    return {\"status\": \"added\"}\n``` -->\n\n<!-- ---\n\n### `@scheduled_task()`\n\n*   **Purpose:** Runs your function automatically on a recurring schedule (like a cron job).\n*   **How it Works:** You configure the schedule via `fngen.yaml` (using cron syntax). `fngen` executes your function on schedule.\n*   **Function Signature:** Standard Python function, typically taking no arguments.\n\n*Example:*\n\n```python\nfrom fngen.powers import scheduled_task\nimport datetime\n\n@scheduled_task()\ndef daily_job():\n    print(f\"Running job at {datetime.datetime.now()}!\")\n```\n\nIn `fngen.yaml`:\n\n```yaml\nschedule: \"0 2 * * *\"  # Runs daily at 2:00 AM UTC\n``` -->\n\n---\n\n### Config Overview + Roadmap\n#### `@webapp` Configuration Options\n\nDeploys your Python web application.\n\n| Option    | Value     | Status      | Description                                                                    |\n| :-------- | :-------- | :---------- | :----------------------------------------------------------------------------- |\n| `framework` | `'fastapi'` | Supported   | Deploy an application built with FastAPI.                                      |\n| `framework` | `'flask'`   | Coming Soon   | Deploy an application built with Flask.                                        |\n| `framework` | `'django'`  | Coming Soon   | Deploy an application built with Django (ASGI/WSGI).                           |\n| `compute`   | `'server'`  | Supported   | Deploys to always-on server instance(s) defined in `fngen.yml`.              |\n| `compute`   | `'serverless'`| Coming Soon | Deploys to event-driven infrastructure that scales to zero when idle.          |\n\n---\n\n#### `@task_worker` Configuration Options\n\nDeploys a function to process background jobs or tasks asynchronously.\n\n| Option    | Value       | Status      | Description                                                                    |\n| :-------- | :---------- | :---------- | :----------------------------------------------------------------------------- |\n| `compute`   | `'server'`    | Supported   | Deploys to always-on worker server instance(s) defined in `fngen.yml`.       |\n| `compute`   | `'serverless'`| Coming Soon | Deploys to event-driven worker infrastructure that scales to zero when idle. |\n\n---\n\n# Projects\n\nYour deployments, code, packages, etc. are organized into Projects.\n\nYou can create a project with the following command:\n\n```bash\nfngen create your_project\n```\n\nList all projects in your account:\n```bash\nfngen projects\n```\n\n---\n\n# Defining Your Deployment\n\nWhen you run `fngen push`, `fngen` packages your code and relevant configuration files. These files help define dependencies, infrastructure resources, and exactly which files are included or excluded.\n\n## Code structure and packaging\n\nWhen you run `fngen push [path/to/code_dir]`, the specified directory becomes your deployment package. `fngen` will package and upload the contents of this directory to the platform for building and deployment.\n\nBy default, `fngen` includes all files and subdirectories within the package directory, with specific rules for inclusion and exclusion defined by `.gitignore`, `.fnignore`, and `.fninclude` files (explained in detail below).\n\nDuring the deployment process, `fngen` scans all `.py` files within your package to discover functions decorated with `fngen.powers` decorators.\n\nThe essential files for a basic deployment are your Python code and a `fngen.yml` file defining your project resources. Note: `fngen.yml` must be located at the root of your deployment package directory.\n\nBelow are some common example directory structures for a deployment package.\n\n### Simple File Structure\nHere's a minimal structure with a single Python file containing your code, and a `fngen.yml` file defining your resources.\n```bash\n.\n\u251c\u2500\u2500 hello.py\n\u2514\u2500\u2500 fngen.yml\n```\n\n### Structure with requirements.txt\nIn most cases, you'll need third-party Python packages. Simply include a `requirements.txt` file at the root of your package, and `fngen` will automatically install the dependencies during the deployment build process.\n```bash\n.\n\u251c\u2500\u2500 requirements.txt\n\u251c\u2500\u2500 hello.py\n\u2514\u2500\u2500 fngen.yml\n```\n\n### Structure with multiple modules\nYou are not confined to a single Python module. You can organize your code across as many `.py` files as needed. fngen will scan all of them for decorated functions.\n```bash\n.\n\u251c\u2500\u2500 requirements.txt\n\u251c\u2500\u2500 hello.py\n\u251c\u2500\u2500 llm.py\n\u251c\u2500\u2500 run_analysis.py\n\u2514\u2500\u2500 fngen.yml\n```\n\n### Structure with an inner Python package\nIt's common practice to organize larger codebases into Python packages using subdirectories with an `__init__.py` file. This standard structure is fully supported.\n```bash\n.\n\u251c\u2500\u2500 my_project\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 __init__.py\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 annotate_video.py\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 recommend_videos.py\n\u251c\u2500\u2500 requirements.txt\n\u2514\u2500\u2500 fngen.yml\n```\n\n### Structure including git-ignored assets\nIt's good practice to exclude large 'assets' (like data files, videos, images) from your version control (Git) repository using `.gitignore`. However, you will often want to include these in your deployment package. You can achieve this by adding entries to a `.fninclude` file at the root of your package. fngen respects `.gitignore` for exclusions but prioritizes `.fninclude` for inclusions. You can also use `.fnignore` for explicit exclusions (see [`.fnignore`](#.fnignore) and [`.fninclude`](#.fninclude) sections for details).\n```bash\n.\n\u251c\u2500\u2500 .gitignore\n\u251c\u2500\u2500 .fninclude\n\u251c\u2500\u2500 assets\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 big_video.mp4\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 gorilla.png\n\u251c\u2500\u2500 my_project\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 __init__.py\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 annotate_video.py\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 recommend_videos.py\n\u251c\u2500\u2500 requirements.txt\n\u2514\u2500\u2500 fngen.yml\n```\n\n## requirements.txt\n\nIf your code includes a `requirements.txt` file, `fngen` will **automatically install dependencies** for each run mode.\n\nUnder the hood, it simply runs:\n\n```bash\npip install -r requirements.txt\n```\n\nbefore setting up the deployment or runtime environment.\n\nYou don't need to do anything special \u2014 just make sure your dependencies are correctly listed in your `requirements.txt`.\n\n> \u2705 *Best practice:* Always commit your `requirements.txt` alongside your code.\n\n---\n\n## fngen.yml\n\nYour `fngen.yml` file, placed at the root of your project directory, is where you define project-level configuration and the infrastructure **Resources** required by your `fngen` Powers.\n\nCurrently, `fngen.yml` is primarily used to define configurations for **server** compute resources. Support for configuring serverless resources will be added in the future.\n\n### Defining Your Server Fleet\n\nPowers that require persistent, always-on compute, such as `@webapp(compute='server')` or `@task_worker(compute='server')`, rely on server resources defined in your `fngen.yml` under the `servers:` key.\n\nYou define the composition of your server **fleet** by listing one or more server configurations using `name`, `size`, and `region`. `fngen` will provision a fleet of server instances based on these definitions. For detailed pricing information on server sizes, please refer to the [Pricing](#pricing) section.\n\n**Example:**\n\n```yaml\n# fngen.yml\nservers:\n  - name: web-server-class # Required: A unique name for this server definition within your project. Used for identification in the config.\n    size: s              # Required: The server type tier. Choose one from the table below (see Pricing section).\n    region: us-west      # Required: The geographic region for deployment (e.g., us-west, us-east, eu-central).\n# You can define multiple server types to include in your fleet:\n  - name: worker-server-class\n    size: xl\n    region: us-west\n```\n*Explanation:* In this example, you are defining a server fleet that will include server instances of size `s` located in `us-west` and server instances of size `xl` also in `us-west`. The `name` field (`web-server-class`, `worker-server-class`) is purely for identifying these different definitions within your `fngen.yml`.\n\n### How `compute='server'` Powers Use Your Fleet\n\nWhen you deploy your project with `fngen push`, any function decorated with a Power using `compute='server'` (like `@webapp` or `@task_worker`) will be deployed to **every single server instance** within the fleet you defined in `fngen.yml`.\n\n*   **Horizontal Scaling:** Your entire application code is replicated across all provisioned servers.\n*   **Automatic Load Balancing:** For `@webapp` functions, `fngen` automatically sets up and manages a load balancer to distribute incoming web traffic across all web servers in your fleet.\n*   **Shared Fleet:** `@webapp` and `@task_worker` functions using `compute='server'` share the *same* server fleet. Your web app runs on the same instances as your task workers.\n\nBy defining multiple server configurations (e.g., one `s` and one `xl`), you create a heterogeneous fleet, and your `compute='server'` workloads will run on instances of *both* types.\n\n*(Future: This file may include configurations for `serverless` compute or other `fngen`-managed resources.)*\n\n\n## .fninclude\n\nUse .fninclude to include .gitignore'd files in your deployment package when you run `fngen push`.\n\nTypically, you don't want to include certain resources in your git repo, but you do want to include them in your deployment package.\n\n## .fnignore\n\nUse .fnignore to ignore files from being included in your deployment package when you run `fngen push`.\n\nUses .gitignore syntax.\n\nNote: `fngen push` also respects your .gitignore; .fnignore is used to ignore stuff that you may want to include in your git repo. (This is rare, but it can happen).\n\n## Environment Variables\n\nManaging application configuration, secrets, and credentials securely is essential. `fngen` provides a built-in mechanism for managing environment variables for your projects.\n\n### Purpose\n\nEnvironment variables are key-value pairs injected into the runtime environment where your functions are executed. They are commonly used for:\n\n*   Database connection strings\n*   API keys for third-party services\n*   Configuration flags (e.g., `DEBUG=True`)\n*   Sensitive information that should not be hardcoded or committed to version control.\n\n### Setting Environment Variables\n\nYou can upload environment variables to your fngen project using the `fngen set_env` command. This command reads variables from a standard `.env` file.\n\n1.  **Create a `.env` file:** In your project directory (or any location), create a file named `.env` (or any name you prefer). Add your variables using the `KEY=VALUE` format, one per line:\n\n    ```dotenv\n    DATABASE_URL=postgres://user:password@host:port/database\n    STRIPE_SECRET_KEY=sk_live_...\n    API_TIMEOUT_SECONDS=30\n    ```\n\n    > **Important:** Do **not** commit your `.env` file containing secrets to your version control system (like Git). Add it to your `.gitignore` file.\n\n2.  **Upload with the CLI:** Use the `set_env` command, specifying your project name and the path to your `.env` file.\n\n    ```bash\n    fngen set_env my-project .env\n    ```\n\nThis command securely uploads the variables to the fngen platform. They are encrypted at rest and injected into the runtime environment of your project's deployed functions. Uploading a variable with the same key will overwrite its existing value.\n\n### Accessing Environment Variables in Your Code\n\nInside any function deployed with a `fngen` Power, you can access environment variables using Python's standard `os` module:\n\n```python\nimport os\n\nfrom fngen.powers import webapp\n\n@webapp(framework='fastapi', compute='server')\ndef my_app_with_env():\n    from fastapi import FastAPI\n    app = FastAPI()\n\n    @app.get(\"/secret\")\n    def get_secret():\n        # Accessing an environment variable\n        # Updated environment variable prefix\n        secret_key = os.environ.get(\"MY_SUPER_SECRET\")\n        if not secret_key:\n            return {\"error\": \"MY_SUPER_SECRET not set\"}, 500\n        return {\"secret\": secret_key}\n\n    return app\n\n# You would set MY_SUPER_SECRET using `fngen set_env my-project .env`\n# where .env contains: MY_SUPER_SECRET=its_a_secret!\n```\n\nEnvironment variables are available to all functions within a project, regardless of the Power used.\n\n---\n\n# Authentication and API Keys\n\nTo interact with the fngen platform and deploy your code, you need to authenticate your fngen CLI and SDK using an API key. Your API key links your local tools to your fngen account and projects.\n\n## Obtaining Your API Key\n\nYour API key is generated within your fngen account dashboard (details on accessing the dashboard will be provided separately). Treat your API key like a password \u2013 keep it secure and do not share it publicly.\n\n## Configuring Authentication\n\nYou can configure your API key for the `fngen` CLI and SDK in two primary ways:\n\n1.  **Configuration File (Recommended):**\n    *   Create a directory named `.fngen` in your user's home directory (`~/.fngen/`).\n    *   Inside this directory, create a file named `credentials.yml`.\n    *   Add your API key to this file in the following format:\n\n        ```yaml\n        api_key: your_fngen_api_key_here\n        ```\n    *   Make sure this file has restricted permissions (`chmod 600 ~/.fngen/credentials.yml`) to protect your API key.\n\n2.  **Environment Variable:**\n    *   Set the `FNGEN_API_KEY` environment variable in your terminal session or shell profile.\n\n        ```bash\n        export FNGEN_API_KEY=your_fngen_api_key_here\n        ```\n    *   This method is often used in CI/CD pipelines or temporary setups. Note that environment variables can sometimes be less secure than a properly permissioned configuration file.\n\nThe `fngen` CLI and SDK will check for the environment variable first, and if not found, will look for the `credentials.yml` file.\n\n## Verifying Your Authentication\n\nUse the `fngen connect` command to verify that your authentication is set up correctly and you can connect to the fngen platform.\n\n```bash\nfngen connect\n```\n\nIf successful, this command will confirm your connection and display the email address associated with your account.\n\n\n---\n\n# Logging and Monitoring\n\nObservability is key to understanding the behavior of your deployed applications and tasks, diagnosing issues, and monitoring performance. `fngen` provides integrated logging capabilities for all your deployed functions.\n\n## What Gets Logged?\n\nfngen captures standard output (`stdout`) and standard error (`stderr`) from your Python functions. This means any `print()` statements or output from standard Python logging libraries (like `logging`) within your decorated functions will be automatically collected and made available through the fngen platform.\n\nAdditionally, fngen platform events related to your project (deployments, task dispatches, scaling events, errors) are also included in the logging stream.\n\n## Accessing Logs via the CLI\n\nThe primary way to access logs is using the `fngen logs` command.\n\n```bash\nfngen logs [project_name] [options]\n```\n\nAs detailed in the [CLI section](#fngen-logs-project), this command allows you to view recent logs, follow logs in real-time, and filter by Power, function, task ID, time range, or log level.\n\n**Examples:**\n\n*   View the last 100 lines of logs for your project:\n    ```bash\n    fngen logs my-project\n    ```\n\n*   Stream logs in real-time:\n    ```bash\n    fngen logs my-project --follow\n    ```\n\n*   Filter logs for a specific task worker function:\n    ```bash\n    fngen logs my-project --power task_worker --function process_order\n    ```\n\n*   View logs for a specific web request (details on how to find request IDs coming soon):\n    ```bash\n    fngen logs my-project --request-id abcdef123456\n    ```\n\n*   See errors from the last hour:\n    ```bash\n    fngen logs my-project --level ERROR --since 1h\n    ```\n\n## Using Python's `logging` Module\n\nWhile `print()` works fine for simple output, using Python's built-in `logging` module provides more structure, severity levels, and context for your logs. fngen fully supports this.\n\n```python\nimport logging\nfrom fngen.powers import task_worker\n\n# Configure basic logging (optional, but good practice)\nlogging.basicConfig(level=logging.INFO)\nlogger = logging.getLogger(__name__)\n\n@task_worker(compute='server')\ndef process_data(data_payload: dict):\n    \"\"\"\n    Processes data received via a task.\n    \"\"\"\n    try:\n        logger.info(f\"Received data payload: {data_payload}\")\n        # ... processing logic ...\n        logger.info(\"Data processing successful\")\n        # You can log at different levels:\n        # logger.warning(\"Something unusual happened\")\n        # logger.error(\"An error occurred during processing\")\n    except Exception as e:\n        logger.exception(f\"Error processing data: {e}\") # Logs error and traceback\n        raise # Re-raise the exception if needed\n```\n\nLogs generated using `logging.info()`, `logging.error()`, etc., will appear in the `fngen logs` output with their respective severity levels.\n\n## Future Monitoring Features\n\nWhile basic logging is available now, future versions of fngen will include more advanced monitoring features such as:\n\n*   Metrics (request latency, error rates, task queue depth)\n*   Distributed tracing\n*   Enhanced log searching and filtering in a web dashboard\n\n---\n\n# `fngen` CLI\n\nThe fngen Command Line Interface (CLI) is your primary tool for interacting with the fngen platform, managing your projects, and deploying your code.\n\nEnsure you have the fngen CLI installed and configured with your API key before proceeding.\n\n```bash\npip install fngen # Update pip install command\n```\n\n## Authentication\n\nThe CLI requires authentication to interact with your fngen account. You can configure your credentials in `~/.fngen/credentials.yml` or by setting the `FNGEN_API_KEY` environment variable.\n\nUse the `connect` command to verify your setup.\n\n## Commands\n\nHere are the most commonly used fngen CLI commands:\n\n### `fngen connect`\n\n*   **Purpose:** Verify your authentication credentials and connectivity to the fngen platform.\n*   **Usage:**\n    ```bash\n    fngen connect\n    ```\n*   **Details:** Checks if your API key (from `~/.fngen/credentials.yml` or `FNGEN_API_KEY`) is valid. If successful, it will return the email address associated with the authenticated account.\n*   **Example:**\n    ```bash\n    fngen connect\n    # Output: \u2705  Connected [user@example.com]\n    ```\n\n### `fngen create [project]`\n\n*   **Purpose:** Create a new fngen project in your account.\n*   **Usage:**\n    ```bash\n    fngen create [project_name]\n    ```\n*   **Details:** Project names must be unique across your fngen account. Creating a project sets up the necessary infrastructure scaffolding on the platform side.\n*   **Example:**\n    ```bash\n    fngen create my-new-project\n    ```\n\n### `fngen projects`\n\n*   **Purpose:** List all fngen projects associated with your account.\n*   **Usage:**\n    ```bash\n    fngen projects\n    ```\n*   **Details:** Displays a list of your project names.\n*   **Example:**\n    ```bash\n    fngen projects\n    # Output:\n    # my-new-project\n    # another-app\n    # marketing-site\n    ```\n\n### `fngen push [project] [path/to/code_dir]`\n\n*   **Purpose:** Package and deploy your Python code to a specific project.\n*   **Usage:**\n    ```bash\n    fngen push [project_name] [path/to/code_directory]\n    ```\n*   **Details:** This command is the core deployment action.\n    *   It reads your project configuration (`fngen.yml`), dependencies (`requirements.txt`), and inclusion/exclusion rules (`.gitignore`, `.fnignore`, `.fninclude`).\n    *   It packages your code directory.\n    *   It uploads the package to the fngen platform.\n    *   fngen then builds the necessary environment and deploys your functions according to their defined **Powers**.\n    *   If `[path/to/code_directory]` is omitted, it defaults to the current directory (`.`).\n*   **Example:**\n    ```bash\n    # Deploy code from the current directory to 'my-website' project\n    fngen push my-website .\n\n    # Deploy code from a specific path to 'another-app' project\n    fngen push another-app /home/user/code/another_app\n    ```\n\n### `fngen run_task [project] 'function_name' 'payload_json'`\n\n*   **Purpose:** Dispatch a new job execution for a function decorated with `@task_worker`.\n*   **Usage:**\n    ```bash\n    fngen run_task [project_name] 'your_function_name' '{\"arg1\": \"value\", \"arg2\": 123, ...}'\n    ```\n*   **Details:** The `function_name` must correspond to a function decorated with `@task_worker` in your deployed code. The `payload_json` must be a valid JSON string that maps to the parameters expected by your task worker function.\n*   **Example:** (Using the `process_order` example function)\n    ```bash\n    fngen run_task my-project 'process_order' '{\"order_id\": 101, \"customer_email\": \"test@example.com\", \"items\": [{\"item_id\": 5, \"qty\": 1}]}'\n    ```\n\n### `fngen set_env [project] [path/to/.env]`\n\n*   **Purpose:** Securely upload environment variables from a `.env` file to your project.\n*   **Usage:**\n    ```bash\n    fngen set_env [project_name] [path/to/.env_file]\n    ```\n*   **Details:** Reads key-value pairs from the specified `.env` file (standard format: `KEY=VALUE`). These variables are securely stored on the platform and automatically injected into the runtime environment whenever your project's functions are executed (web requests, tasks, etc.). Existing variables with the same name will be overwritten.\n*   **Example:**\n    ```bash\n    fngen set_env my-project .env\n    ```\n\n### `fngen logs [project]`\n\n*   **Purpose:** View logs generated by your deployed functions and the fngen platform for your project.\n*   **Usage:**\n    ```bash\n    fngen logs [project_name] [options]\n    ```\n*   **Details:** Accesses the centralized logging stream for your project. Useful for debugging, monitoring, and seeing the output of your `print()` statements or logging calls. If `[project_name]` is omitted when run inside a project directory, it defaults to the current project.\n*   **Options:**\n    *   `--follow`, `-f`: Stream new logs in real-time (like `tail -f`).\n    *   `--power [power_name]`: Filter logs to show only those originating from a specific Power (e.g., `webapp`, `task_worker`).\n    *   `--function [function_name]`: Filter logs to show only those originating from a specific decorated function name.\n    *   `--task-id [task_id]`: Filter logs to show only those associated with a specific task worker job execution ID.\n    *   `--since [duration]`: Show logs since a specific time duration (e.g., `10m`, `1h`, `24h`).\n    *   `--level [level]`: Filter logs by severity level (e.g., `INFO`, `WARNING`, `ERROR`).\n*   **Examples:**\n    ```bash\n    # Show recent logs for the current project\n    fngen logs\n\n    # Follow logs for 'my-website' project\n    fngen logs my-website --follow\n\n    # Show logs from webapp functions in the last 30 minutes\n    fngen logs my-website --power webapp --since 30m\n\n    # View logs specifically for a failed task\n    fngen logs my-project --task-id abc123xyz\n    ```\n\n### `fngen destroy [project]`\n\n*   **Purpose:** Permanently delete a project and all associated resources (servers, data, configurations, logs).\n*   **Usage:**\n    ```bash\n    fngen destroy [project_name]\n    ```\n*   **Details:** This is a **destructive** and irreversible action. You will typically be prompted to confirm before deletion proceeds. Use with caution.\n*   **Example:**\n    ```bash\n    fngen destroy my-old-project\n    ```\n\n*(Future: Mention `fngen --help` and `fngen [command] --help` for more detailed CLI help).*\n\n---\n\n# Pricing\n\nfngen pricing is based on the server resources you provision and utilize for your applications and tasks. We aim for simple, predictable costs.\n\n### Server Pricing\n\nWhen you use `compute='server'` for your `webapp` or `task_worker` Powers, you define a fleet of servers in your `fngen.yml` file based on size and region. You are charged based on the size and duration of these server instances.\n\nThe table below shows the available server types, their specifications, and estimated monthly pricing per instance.\n\n| Server Type (`size`) | vCPU | RAM    | Disk   | Transfer | Est. Cost (USD/mo) |\n| :------------------- | :--- | :----- | :----- | :------- | :----------------- |\n| `xs` | 1    | 0.5 GB | 10 GB  | 0.5 TB   | ~$4                |\n| `s`                  | 1    | 1 GB   | 25 GB  | 1 TB     | ~$6                |\n| `m`                  | 1    | 2 GB   | 50 GB  | 2 TB     | ~$12               |\n| `l`                  | 2    | 2 GB   | 60 GB  | 3 TB     | ~$18               |\n| `xl`                 | 2    | 4 GB   | 80 GB  | 4 TB     | ~$24               |\n| `2xl`     | 4    | 8 GB   | 160 GB | 5 TB     | ~$48               |\n| `3xl`    | 8    | 16 GB  | 320 GB | 6 TB     | ~$96               |\n\n*(Pricing for serverless compute and other future resource types will be added here.)*\n\n### What's Included / No Extra Cost\n\nfngen abstracts away significant infrastructure complexity and management overhead. The following are included as part of the platform fee covered by your server instance costs:\n\n*   **Infrastructure Provisioning:** Setting up servers, networking, etc.\n*   **Deployment Pipeline:** Building, packaging, and deploying your code.\n*   **Automatic HTTPS:** SSL certificate management and renewal for web applications.\n*   **Load Balancing:** Distributing traffic across your `webapp` server fleet.\n*   **Task Queuing Infrastructure:** The messaging and queuing system for `@task_worker`.\n*   **Basic Monitoring & Logging Access:** Tools to observe your applications (detailed sections on these coming soon).\n*   **Bandwidth:** Includes the specified data transfer per server size tier.\n\nYou only pay for the server instances you define in your `fngen.yml` or the usage of future metered resources like serverless functions.\n\n---\n\n# FAQ\n\n### Why Python?\n\nThere's a great saying that goes:\n> \"python isn't the best language for anything, but it's the second best language for everything\"\n\nSo, when building a platform focused on delivering powerful, high-leverage solutions with code, it seems like the best all-purpose language to focus on.\n\nPlus, we just love Python.\n\nP.S., Need other tools? You can often integrate them via a standard Python interface within your `fngen`-activated functions.\n\n---\n\n### Why Python *functions* specifically?\n\nPython functions serve as a versatile and well-defined unit for specifying discrete pieces of logic. By centering `fngen` around functions, we provide a simple, consistent contract for activating various **Powers**. This approach promotes modularity, testability, and allows `fngen` to generate the appropriate execution environment and infrastructure tailored precisely to that function's defined role.\n\n---\n\n### Functional Infra: The Power of Purpose-Built Infrastructure\n\nBuilding and deploying powerful applications requires more than just writing code. It requires supporting infrastructure \u2013 things like servers, networks, load balancers, message queues, and more. Traditionally, setting up and managing this infrastructure has been a complex and time-consuming task for developers.\n\n`fngen` introduces the concept of **Functional Infra**. This refers to the **minimum, pre-packaged infrastructure** automatically provisioned and managed by `fngen` specifically to support a certain Python function and its designated **Power**.\n\nThink of each Power as a blueprint for a specific type of application function, and Functional Infra as the engine and support system needed to make that blueprint a reality in a production environment.\n\nHere are some examples of how Functional Infra pairs with `fngen` Powers:\n\n*   When you use the `@webapp()` Power, `fngen` provisions the **Functional Infra for Web Applications**. This typically includes:\n    *   Server instance(s) to run your application code (`compute='server'`).\n    *   A load balancer to distribute incoming web traffic across your servers.\n    *   Managed DNS and automatic HTTPS/SSL certificates.\n    *   Necessary networking and security configurations.\n    *   *(For `compute='serverless'` coming soon: Event triggers, scaling configurations, potentially API gateways)*\n\n*   When you use the `@task_worker()` Power, `fngen` provisions the **Functional Infra for Background Tasks**. This typically includes:\n    *   A managed message queue to receive and hold incoming task payloads.\n    *   Server instance(s) to run your worker function (`compute='server'`).\n    *   A management API and routing layer to dispatch payloads to your worker function instances.\n    *   *(For `compute='serverless'` coming soon: Event triggers, scaling configurations based on queue depth)*\n\n*   When you use the `@web_form()` Power, `fngen` provisions the **Functional Infra for Interactive Functions**. This typically includes:\n    *   A simple web server to host the automatically generated HTML form.\n    *   An endpoint to receive form submissions.\n    *   The necessary routing to call your Python function with the submitted data.\n\n**The Value of Functional Infra:**\n\nBy providing Functional Infra, `fngen` significantly reduces the operational burden on developers. You don't need to become an infrastructure expert to deploy a web app or set up a task queue. You simply define what your function *is* meant to do using a Power, and `fngen` handles provisioning, configuring, and managing the underlying infrastructure required for that purpose.\n\nThis allows you to:\n\n*   **Move Faster:** Deploy production-ready features in minutes, not hours or days.\n*   **Reduce Complexity:** Avoid managing servers, networking rules, load balancers, and queues yourself.\n*   **Focus on Code:** Spend more time writing the Python logic that delivers value, rather than wrangling infrastructure.\n\nAs `fngen` grows, we will continue to introduce new Powers, each bringing its own flavor of purpose-built Functional Infra to support a wider range of Python use cases \u2013 all while maintaining the simple, function-centric \"annotate and push\" workflow.\n\n---\n\n# TL;DR\n\n1.  Write a Python function.\n2.  Give it a **Power** (decorate it).\n3.  `fngen push` it.\n\n`fngen` handles the rest.\n\n---\n\n# Roadmap\n\nThis section outlines the current capabilities of `fngen` and provides a look ahead at planned features and enhancements.\n\n## General Roadmap & Future Enhancements\n\nThe following areas represent ongoing development and future additions to the `fngen` platform and documentation:\n\n*   **Web Dashboard:** Development of a comprehensive web-based dashboard for project management, log viewing, monitoring, and configuration.\n*   **Advanced Monitoring:** Expanding beyond basic logging to include metrics (e.g., request latency, error rates, queue depth), distributed tracing, and enhanced visualization in the dashboard.\n*   **CI/CD Integration:** Providing more detailed guidance, examples, and potentially specific features to streamline integration into Continuous Integration and Continuous Deployment pipelines.\n*   **Custom Build Environment:** Exploring ways for users to define custom environments, such as specifying OS-level dependencies or providing custom build scripts, for more complex project requirements.\n*   **Enhanced Error Handling & Debugging:** Tools and features to make identifying and diagnosing runtime errors easier.\n*   **Notifications:** Configuring alerts based on application logs or metrics (e.g., error rate spikes, high latency).\n*   **Database & Service Integrations:** Potentially offering managed data services or simplified connections to external databases/services.\n*   **Expanded Documentation:** Continuously improving clarity, adding more examples, tutorials, and addressing common use cases.\n\n### Planned Powers (Coming Soon)\n\nThese Powers are planned for future releases:\n\n*   **`@web_form()`:** Automatically generate a simple web form UI from your function signature.\n*   **`@scheduled_task()`:** Run your function automatically on a recurring schedule (like a cron job).\n*   *(Potential future powers for packaging, CLI tools, UI generation, etc.)*\n\nWe are actively working on expanding the capabilities of `fngen` to cover a wider range of Python application patterns. Stay tuned for updates!\n",
    "bugtrack_url": null,
    "license": "MIT License\n        \n        Copyright (c) 2025, supadef, Inc.\n        \n        Permission is hereby granted, free of charge, to any person obtaining a copy\n        of this software and associated documentation files (the \"Software\"), to deal\n        in the Software without restriction, including without limitation the rights\n        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell\n        copies of the Software, and to permit persons to whom the Software is\n        furnished to do so, subject to the following conditions:\n        \n        The above copyright notice and this permission notice shall be included in all\n        copies or substantial portions of the Software.\n        \n        THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\n        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\n        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\n        SOFTWARE.",
    "summary": "Give your Python functions superpowers",
    "version": "0.9.4",
    "project_urls": null,
    "split_keywords": [
        "infra",
        " infrastructure",
        " deployment"
    ],
    "urls": [
        {
            "comment_text": null,
            "digests": {
                "blake2b_256": "51598134e2f4729ad4d003c705bade7d6a5afb75b948ebaac1e41fb955ff4a9d",
                "md5": "a209096f7000c42b541b1b2790240022",
                "sha256": "c6b3fd192433aa9059a854d86d037362028f3eeece6f8d00ad90cdf4638bd6e4"
            },
            "downloads": -1,
            "filename": "fngen-0.9.4-py3-none-any.whl",
            "has_sig": false,
            "md5_digest": "a209096f7000c42b541b1b2790240022",
            "packagetype": "bdist_wheel",
            "python_version": "py3",
            "requires_python": ">=3.8",
            "size": 29806,
            "upload_time": "2025-07-26T01:48:47",
            "upload_time_iso_8601": "2025-07-26T01:48:47.009841Z",
            "url": "https://files.pythonhosted.org/packages/51/59/8134e2f4729ad4d003c705bade7d6a5afb75b948ebaac1e41fb955ff4a9d/fngen-0.9.4-py3-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": null,
            "digests": {
                "blake2b_256": "7de06a0a9ab6e7570b7069f4dca780da6c6e1d7c78b476b1395a60c64c337ec0",
                "md5": "9cffe2ed0dd59d3da1ed42d63d38b004",
                "sha256": "9b12419150410c7402d5f3cb70edd7ab49b4b55c495c7d2fd57287e6ccbc01cd"
            },
            "downloads": -1,
            "filename": "fngen-0.9.4.tar.gz",
            "has_sig": false,
            "md5_digest": "9cffe2ed0dd59d3da1ed42d63d38b004",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": ">=3.8",
            "size": 51390,
            "upload_time": "2025-07-26T01:48:49",
            "upload_time_iso_8601": "2025-07-26T01:48:49.516387Z",
            "url": "https://files.pythonhosted.org/packages/7d/e0/6a0a9ab6e7570b7069f4dca780da6c6e1d7c78b476b1395a60c64c337ec0/fngen-0.9.4.tar.gz",
            "yanked": false,
            "yanked_reason": null
        }
    ],
    "upload_time": "2025-07-26 01:48:49",
    "github": false,
    "gitlab": false,
    "bitbucket": false,
    "codeberg": false,
    "lcname": "fngen"
}