flox-publish

# Flox Package Publishing Guide

## Core Commands

```bash
flox publish                    # Publish all packages
flox publish my_package         # Publish single package
flox publish -o myorg package   # Publish to organization
flox publish -o myuser package  # Publish to personal namespace
flox auth login                 # Authenticate before publishing
```

## Publishing Workflow: Development to Runtime

Publishing packages enables a clear separation between **development** and **runtime/consumption**:

### The Complete Workflow

**Phase 1: Development Environment**
```toml
# .flox/env/manifest.toml (in git with source code)
[install]
gcc.pkg-path = "gcc13"
make.pkg-path = "make"
python.pkg-path = "python311Full"

[build.myapp]
command = '''
  python setup.py build
  mkdir -p $out/bin
  cp build/myapp $out/bin/
'''
version = "1.0.0"
```

Developers work in this environment, commit `.flox/` to git alongside source code.

**Phase 2: Build and Publish**
```bash
# Build the package
flox build myapp

# Publish to catalog
flox publish -o myorg myapp
```

The published package contains BINARIES/ARTIFACTS (what's in `$out/`), NOT source code.

**Phase 3: Runtime Environment**
```toml
# Separate environment (can be pushed to FloxHub)
[install]
myapp.pkg-path = "myorg/myapp"  # The published package
```

Consumers create runtime environments and install the published package. No build tools needed, no source code exposed.

**Key insight**: You don't install the published package back into the development environment - that would be circular. Published packages are installed into OTHER environments (different projects, production, etc.).

## Publishing to Flox Catalog

### Prerequisites
Before publishing:
- Package defined in `[build]` section or `.flox/pkgs/`
- Environment in Git repo with configured remote
- Clean working tree (no uncommitted changes)
- Current commit pushed to remote
- All build files tracked by Git
- At least one package installed in `[install]`

### Au