Version 1
...0.7 is the first version that I actually got to work from the test pypi package manager.
This week as you might be able to infer from the myriad clues in the opening sentences my class was tasked with making our first releases to the package managers in our language of choosing with whatever tools of our choosing and I had a few hiccups along the way but eventually got my Python static site generator to build into a working pypi package manager release that could be installed from pypi and executed right from the command line.
Getting started with pypi
I followed the Packaging Python Projects instructions, and it worked until I tried to install what I had done and run it :)
For my first attempt I changed the directory structure of my project to more closely match the sample that was given by adding a package folder underneath the src folder and I added an init.py inside the package so that the directory would be treated as a package. Due to the directory structure I also changed the pyproject.toml settings for my pytest to know where they were getting their imports from since there was a new folder between src and the python source code they were testing.
One of the few steps that you have to take to be able to push to pypi is to build your project using hatchling, setuptools, Flit, or any other one of Pythons many build tool options. I initially used Hatchling and did not give thought to the fact that I wanted to be able to run my program from the command line as a stand alone program as well so when I installed it and tried to I could not. It looked like this:
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"
I did a little bit of digging and found that what I wanted to achieve was possible, if I used a different build tool called setuptools there was the possibility to specify an entrypoint method given a custom CLI command. So I tried to do that, but it failed. I then went to the docs which are AMAZING and for good measure also found the following article with a script example. From these I learned that my main method that I chose as my entry point could not have any arguments passed to it, instead it would have to pull those from sys and parse them in the body.
Initially what I was doing was I had a main method that took the arguments passed on the command line as a parameter, I had to change this, I took what I had in my main method and copy and pasted it into a new interim method called take_args and my new main method body was just calling that method as follows: take_args(sys.argv[1:]). This way instead of if __name__ == "__main__":main(sys.argv[1:]) I could have a clean main() as the method to be called for my script which I then specified in the .toml as follows:
[project.scripts]
ssgen = "super_site_generator_package.main:main"
Then I tagged and cleaned it up, built, pushed and installed to test and this time it worked. It sounds reasonably clean and fast when I write it like this but in reality this took me 6 or 7 tries and quite a few hours, I added to the version number each time and that's why now it's at v1.0.7.
How to install my pypi package
My site generator is now a stand alone pip package that you can run from the cli with the command ssgen. Originaly the site generators name was going to be something like supersaiyagen in reference to the golden haired super forms in the dragon ball series of anime, in fact that is why the class that does most of the work is called SSJ. I decided to harken back to this namesake with the entrypoint command of ssgen.
The pip package is currently located here: https://test.pypi.org/project/super-site-generator-package/1.0.7/ and can be installed using: pip install -i https://test.pypi.org/simple/ super-site-generator-package==1.0.7
If you so choose you can test it out in a python virtual environement by running py -m venv and then Scripts\activate(on Windows) or /bin/activate(on basically everything else)
Ensure you have pip and that it is updated and try installing using pip install -i https://test.pypi.org/simple/ super-site-generator-package==1.0.7
Just like when you work with the main module directly you can specify all of the arguments right after ssgen like ssgen -vh for example to see version and help. Everything should work the same as is outlined in the table of options below:
Be warned that everything in the specified output directory (./dist by default) will be deleted upon each successful run to be rewritten with the results
| ShortCut | LongOption | Result |
|---|---|---|
| -v | --version | Displays name and version of program |
| -h | --help | Displays a help message with useful information about program and possible options |
| -i | --input | Specify an Input directory or file only .txt suffix will be correctly parsed (requires argument) |
| -o | --ouput | Specify a name for existing directory (optional argument) |
| -c | --config | Specify a json file with all other options within it |
Exterior Testing
To test I asked my brother, who also has some experience with programming. He was able to get my package running relatively easily from the instructions in the README but then pretty quickly realized that it was not working as advertised. This is not a result of how I packaged my code however, I went into the source code and realized that I have problems when single files are input it does not output to the specified output directory but rather to the directory that ssgen is called from. I have some fixes to make. I will keep you posted on how those are coming along in further updates/edits to this post. The title tag is also not changing.
Top comments (0)