Build package from a scratch¶

Overview¶

There can be two way to publish your package: in local or in distributed system.

Build Time¶

Progress¶

Choose your package name
Choose your destination:

****¶

Check time

Package name normalization Project names are "normalized" for use in various contexts. This document describes how project names should be normalized.

Valid non-normalized names A valid name consists only of ASCII letters and numbers, period, underscore and hyphen. It must start and end with a letter or number. This means that valid project names are limited to those which match the following regex (run with re.IGNORECASE):

^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$ Normalization The name should be lowercased with all runs of the characters ., -, or _ replaced with a single - character. This can be implemented in Python with the re module:

import re

def normalize(name):
    return re.sub(r"[-_.]+", "-", name).lower()

oneline on bash

import re

def normalize(name):
    return re.sub(r"[-_.]+", "-", name).lower()

This means that the following names are all equivalent:

friendly-bard (normalized form)

Friendly-Bard

FRIENDLY-BARD

friendly.bard

friendly_bard

friendly--bard

FrIeNdLy-..-bArD (a _terrible way to write a name, but it is valid)

Creating the package files¶ You will now add files that are used to prepare the project for distribution. When you’re done, the project structure will look like this:

packaging_tutorial/
├── LICENSE
├── pyproject.toml
├── README.md
├── src/
│   └── example_package_YOUR_USERNAME_HERE/
│       ├── __init__.py
│       └── example.py
└── tests/

https://packaging.python.org/en/latest/specifications/core-metadata/

Contents

Metadata-Version

Name

Version

Dynamic (multiple use)

Platform (multiple use)

Supported-Platform (multiple use)

Summary

Description

Description-Content-Type

Keywords

Home-page

Download-URL

Author

Author-email

Maintainer

Maintainer-email

License

Classifier (multiple use)

Requires-Dist (multiple use)

Requires-Python

Requires-External (multiple use)

Project-URL (multiple-use)

Provides-Extra (multiple use)

Rarely Used Fields

Provides-Dist (multiple use)

Obsoletes-Dist (multiple use)

Read through https://packaging.python.org/en/latest/specifications/

Ensure pip, setuptools, and wheel are up to date While pip alone is sufficient to install from pre-built binary archives, up to date copies of the setuptools and wheel projects are useful to ensure you can also install from source archives:

Unix/macOS

python3 -m pip install --upgrade pip setuptools wheel

Source Distributions vs Wheels pip can install from either Source Distributions (sdist) or Wheels, but if both are present on PyPI, pip will prefer a compatible wheel. You can override pip`s default behavior by e.g. using its –no-binary option.

Wheels are a pre-built distribution format that provides faster installation compared to Source Distributions (sdist), especially when a project contains compiled extensions.

If pip does not find a wheel to install, it will locally build a wheel and cache it for future installs, instead of rebuilding the source distribution in the future.

https://packaging.python.org/en/latest/tutorials/installing-packages/

Installing from VCS Install a project from VCS in "editable" mode. For a full breakdown of the syntax, see pip’s section on VCS Support.

Unix/macOS python3 -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git # from git python3 -m pip install -e SomeProject @ hg+https://hg.repo/some_pkg # from mercurial python3 -m pip install -e SomeProject @ svn+svn://svn.repo/some_pkg/trunk/ # from svn python3 -m pip install -e SomeProject @ git+https://git.repo/some_pkg.git@feature # from a branch

CHECK LOCAL STATE

After building your package, you can have a look if all the files are correct (nothing missing or extra), by running the following commands:

tar tf dist/.tar.gz unzip -l dist/.whl This requires the tar and unzip to be installed in your OS. On Windows you can also use a GUI program such as 7zip.

https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

Declare your classifier

https://pypi.org/classifiers/

Repository¶ You can select the repository with which to upload using the -r/--repo option or by setting the HATCH_INDEX_REPO environment variable.

Rather than specifying the full URL of a repository, you can use a named repository from a publish.index.repos table defined in Hatch's config file:

config.toml

[publish.index.repos.private] url = "..." ...

The following repository names are reserved by Hatch and cannot be overridden:

Name Repository main https://upload.pypi.org/legacy/ test https://test.pypi.org/legacy/ The main repository is used by default.

Authentication¶ The first time you publish to a repository you need to authenticate using the -u/--user (environment variable HATCH_INDEX_USER) and -a/--auth (environment variable HATCH_INDEX_AUTH) options. You will be prompted if either option is not provided.

The user that most recently published to the chosen repository is cached, with their credentials saved to the system keyring, so that they will no longer need to provide authentication information.

For automated releasing to PyPI, it is recommended that you use per-project API tokens.

Confirmation¶ You can require a confirmation prompt or use of the -y/--yes flag by setting publishers' disable option to true in either Hatch's config file or project-specific configuration (which takes precedence):

config.toml pyproject.toml hatch.toml

[publish.index] disable = true

August 27, 2022

Release with VERSION

https://py-pkgs.org/07-releasing-versioning.html

CICD¶

a) Automaticly build document

b) Test run on PIP test version

c) Create test and performance test

d) Create example on build test

e) Deploy Color https://shields.io/category/version

f) Make Release with semantic layer

g) Build component

Reference¶

123123

https://py-pkgs.org/07-releasing-versioning.html

https://github.com/stinodego/poetry-guide

https://www.joyofdata.de/blog/setting-up-a-time-dimension-table-in-mysql/