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:
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!