Skip to content

Coming from Python (apps)

This route is for Python developers evaluating Incan for application code, services, typed domain packages, and deployment-oriented tools.

Choose your route

StartRun the first projectUse the canonical installer and complete the run, test, and release-build loop. First projectBuild a small native commandKeep the readable function-and-module shape while adding explicit exports, tests, and a locked native build. WorkflowCompose a typed processing stepModel an input, return a typed result, split the project into modules, and test both paths. EvaluateCompare Python and IncanCheck ecosystem, runtime, deployment, type, and error-model tradeoffs before adopting.

Build an application-shaped project

The typed data processor and typed API carry familiar model, JSON, file, and service shapes into native 0.5 projects. Their standard-library closures are part of the toolchain's full Loaf, so both tutorials finish with runtime evidence rather than source inspection alone.

Install once

Follow Getting Started for the current installer choices and canonical new → run → test → build loop. If you use Python tooling every day, the pipx option keeps the incan command isolated from project environments; it does not make Incan a Python package runtime.

What transfers

  • Readable functions, named arguments, modules, collections, comprehensions, and model-shaped application code
  • Familiar function, module, and result composition for application work
  • A small amount of syntax around an explicit, testable application core

What changes

  • Result, Option, and ? make ordinary fallibility part of the function contract instead of an exception-only convention.
  • Models and derives move validation and serialization behavior into compiler-visible types.
  • The toolchain produces native binaries through Rust rather than executing source in CPython.
  • A manifest and lockfile own project and dependency facts that Python tools often distribute across several files.

What not to expect

  • CPython compatibility, Python package compatibility, or the ability to import arbitrary PyPI packages
  • Notebook or dataframe compatibility merely because the source syntax is familiar
  • Dynamic monkey-patching as an application extension model

Continue