Setup foundations for packaging and publishing

[inverse]

• Setup CI pipeline on release publish that will automatically push to pypi
• Package up using setup.py - Went for this as I wasn't sure how to use poetry to manage this as there is only a single script vs traditional packaging modules
• Added Makefile to automate build/cleaning

To test local flow

python -m venv .venv
source .venv/bin/activate
pip install -r requirements-dev.txt
make

## Test pipx install 
pipx install dist/decode_config-2022.1.1-py3-none-any.whl 

Resolves #38

[inverse]

Needs a token to be added as a GitHub secret

[inverse]

Had to move it as build is used for packaging :/

[curzon01]

it does... a lot of other work with the start of the new year, be patient for eval

[inverse]

No rush - let me know if you need anything explained 👍🏼

[inverse]

These ignores are here to avoid polluting and accidentally committing invalid things

[curzon01]

I know - but overwrites already existing local ones. Your excludes are not other people excludes :-)

[inverse]

I don't follow? This is scoped to the repository? If anyone was to checkout the project and run make build for example they would have buiild/ and dist/ folders showing as a change with git and would be confusing.

[curzon01]

I know that but how to handle if my working dir contains a different .gitignore? anyway I took now more than 4 hours to try to get it work pypi for both branch for a simple python script file without a result, that was the reason why I used to think of pypi as a single simple python as an overkill

[inverse]

Why would your git repo contain a different .gitignore? Normally these kind of things are scoped to the project so everyone has the same setup. With the exception of global ones which feel like a bit like an anti-pattern to me.

What were/are you struggling with?

My rational for this is to ease install and upgrades. Either with pure pip or by leveraging pipx

e.g. with pipx it would be pipx install decode-config and pipx upgrade decode-config

[curzon01]

To understand the current action status:
The last failed action basically is a result of the updated github release.
I updated release v12.3.0 to v12.3.1 which causes the error creating of the pypi packages using 12.3.0 which already exist.

cause github release update action didn't work, I downgraded release v12.3.1 to v12.3.0 and created a new release v12.3.1.

[inverse]

From what I understand the action is only invoked when the release is published and is based off the new existing tag that it was created on.

so if you had a draft release and updated it, as soon as you publish it that's what it will be based on.

I'm not sure what happens if you update an already published release though - is that what the problem came from updating an already published release?

[curzon01]

exactly, when you update an already published release (that's possible), then the github source file packages are updated but the action access an outdated tag

[inverse]

Trying to reproduce the issue on a new repo

• created release (CI kicked off)
• Update release (name + tag) - CI not kicked off

How did you get yours working?

[curzon01]

same steps as yours but different yml (publish.yml from this repo) from your Init PR - that's why I'm asking