The Test Consequence

I have recently been encouraged to check out pyscaffold. The conversation I had was pretty intense, which led me to – at the very least, run the skeleton.py file that’s in the documentation.

I created a scaffold project folder. The same directions that were used in the DagsHub comparison were used to create the virtual Python environment where I installed pyscaffold.

I followed the documentation, and created a new project using the put up command. I already created a scaffold folder so I decided to name the project test.

After running the put up command. It looked like everything was going to work fantastically, until I decided to try to run the skeleton.py module. I couldn’t figure out how to run it. I read through the auto-generated files and discovered a skeleton.py file located in my src folder that says to uncomment some lines from my setup.cfg file:

Once completed, the program is supposed to run with the following command:

fibonacci 10

The command line kept telling me that the module didn’t exist. I installed things. I searched the internet far and wide. What is a module, anyway? Should everything be located in the source folder? Where’s the main.py file that’s being referenced.

I searched and searched and stared and I was about to give up. As a last result, I decided to run the Python help function to see a list of all of the modules.

I shouldn’t have called my project test.

I putup another project titled myproject and low and behold! I have successfully setup and installed a python project using the pip command that I can run with a single command:

And there we have it – the test consequence. Whoops. If you’re looking for a good way to manage your Python packages, I suspect that pyscaffold could be a great help. Just, beware of naming your project test. Although, in hindsight, I am not so sure why I didn’t name it human. Hrumph!