Proposal: rename `mojo package` and `.mojopkg`

Mojo
1

Hello everyone,

We are proposing to rename mojo package and the .mojopkg file extension.

The current nomenclature is misleading as it conveys to users the notion of a distributable package format. It ultimately isn’t fit for this purpose as it’s essentially serialized MLIR and is tied exactly to the version of the compiler that produced it. This means it has limited use being shared across multiple systems.

The mojo package tool in particular is squatting on space we’d like to free up for a “real” package manager one day ( Open question: what would you like to see from a Mojo package manager? ). In practice we would deprecate the current name for a period, with a warning to users to move to the new tool and/or file extension. After a period we would make it an error to free up the name for a future package manager.

Since mojo package is ultimately a way of pre-compiling Mojo files into a sort of cache, we propose to rename it to mojo precompile.

The choice of file extension has more options that I can see:

  • .mojomliris literal but perhaps exposes its internals too readily
  • .mojopch would mimic pre-compiled headers with which this format shares similarities, although we don’t have the concept of “headers”.
  • .mojoprecmp, .mojopcmp, .mojocmp, etc., all riffs on “pre-compile” with varying verbosities

Other suggestions are welcome - thanks!

2

A very short riff on “pre-compile”: .mojopc

3

I think that precompile would clash with it being architecture independent.

What about mojo bundle-object and .mobject or .mbundle? Everyone knows you don’t ship object files, and that is less reliant on knowing about precompiled headers or MLIR specifically.

4

Interesting. What if instead of “bundle-object” you have just “bundle”?
Also - I’m just thinking - do we need to spell out the full intention in the extension? We could use a documented acronym, e.g. .mmo for “Mojo Mlir Object”.

5

My bid: “mojo artifact”, extension: .mojoart (or, if you want to defy the heavens, .:artist_palette:. Just kidding. No emoji extensions!)

  • aligns with existing build artifact terminology
  • avoids misleading signals like .o / “object file” or .mo/“mojo object file”
  • doesn’t imply distribution, portability, or stability
  • stays within conventional filesystem constraints (no emoji, no surprises)
  • gives clean language across CLI + docs (“emit artifact”, “artifact file”)
  • It is 7 letters long, which is on the long side, but is much cleaner than .mart or .martifact
6

.mojoc, similar to .pyc

Or - since in Python .py to .pyc is 1:1 - perhaps .mojo.bin

7

.mojoc and .mojobc are strong contenders

re: mojo bundle
Imo this is too nice a name. Keep in mind that the .mojopkg file is tied to the exact version of the Mojo compiler that produced it. Generating .mojopkg from a mojo nightly from Date 1 and then using it with a mojo nightly from Date 2 is error prone. Name should reflect that fact. Imo, “bundle” does not hint that at that relationship.

8

Even though it is not a perfect analogy compilers (used to) produce .o files. So you could have .mo or .mojoo

9

Thanks for the suggestions everyone! We are going with mojo precompile and .mojoc.

While we’re on the subject, though, I don’t think we need to be quite so strict about the file extension as we are currently. Since the .mojopkg (as it’s currently known) file format is well defined, we could actually allow any file extension as long as it’s a valid object. We’re mostly talking about the canonical file extension in this discussion.