0

In the django culture, I have encountered the concept of app reuse but not snippet reuse. Here is an example of what I mean by snippet reuse: I have a function getDateTimeObjFromString( sDateTime ), obviously you pass a string date time and it returns a python date-time object.

Back in the late 1980's or early 1990's, I was exposed to the idea of snippet reuse at a FoxPro developers conference. If you write code for a specific problem and find it is useful elsewhere in your project, move it to a project library. If you find that code is useful for other projects, move it to a generic library that can be accessed by all projects.

(At the FoxPro DevCon, they did not call it snippet reuse. I coined that term to make clear that I am referring to reuse of chunks of code smaller than an entire app. The FoxPro DevCon was long ago, I do not remember exactly what they called it.)

I read the most recent "Two Scoops of Django", and it does mention reusing snippets within a single project but I did not find any mention of the concept of snippet reuse across multiple projects.

I wrote and used getDateTimeObjFromString() long before I tackled my django app. It is in packages I keep under /home/Common/pyPacks. On my computers, I set PYTHONPATH=/home/Common/pyPacks, so every project can access the code there. The code for getDateTimeObjFromString() is under a Time subdirectory in a file named Convert.py. So to use the code in any project:

from Time.Convert import getDateTimeObjFromString

My django app downloads data from an API, and that data includes timestamps. It would be nice if the API sent python date time objects, but what you get are strings. Hence the utility of getDateTimeObjFromString().

This is just one example, there are many little functions under /home/Common/pyPacks that I found convenient to access in my django project.

Yes /home/Common/pyPacks are under version control in github and yes I deploy on any particular machine via git pull.

When working on my django project from a development computer, PYTHONPATH works, and I can import the packages. But then I tried running my django app on a server via wsgi.py -- PYTHONPATH is disabled. I can set PYTHONPATH both at the OS and Apache2 level, but python ignores it, the functions cannot import.

I do not want to bother with making my personal generic library an official python package under PyPI.

Does the django community expect me to copy and paste?

I arrived at a work around: make /home/Common/pyPacks a psudeo site-package by putting a "pyPks" symlink in the virtual environment's site-packages directory to /home/Common/pyPacks, adding "pyPks" to the INSTALLED_APPS, then changing all the import statements as follows:

original: 
    from Time.Convert import getDateTimeObjFromString
work around update:
    from pyPks.Time.Convert import getDateTimeObjFromString

I also had to update all my generic library files to handle both absolute imports via PYTHONPATH and relative imports.

How to fix “Attempted relative import in non-package” even with init.py

Is there a better way to reuse snippets in a django project?

Rick Graves
  • 517
  • 5
  • 11
  • Make it an instalkabe package (with a `setup.py`) and install it into your project. Also it might be a good idea to have a look at the naming conventions in PEP 8. – Klaus D. May 19 '19 at 01:29
  • I assume you mean "installable" package? It seems to me your suggestion is more work than my workaround. – Rick Graves May 19 '19 at 01:36
  • In many cases it is more work to do something right than to make it just work. – Klaus D. May 19 '19 at 01:44
  • 1) Is installing my library into my project a fancy way to copy and paste? 2) It seems to me your suggestion is more work than my workaround, as making my library installable would be an extra step. 3) When I update my library, no extra steps are required using my workaround, while I assume extra steps would be required if I had installed the library as you suggest. – Rick Graves May 19 '19 at 01:48
  • As long as you work alone on your project and don't use anything like CI/CD or container or other automated development process tool you should be fine with your "workaround". – Klaus D. May 19 '19 at 01:58
  • I'm not sure I'm understanding correctly. The code in /home/Common/pyPacks just lives on your "computers"? Is it version controlled? How do you keep your computers in sync? It seems like copying it around to all your computers manually is actually more work than pushing it up to github (or similar) and pip installing it from github (it doesn't have to be on PyPI to be pip installable). – Brad Martsberger May 19 '19 at 02:35
  • The code in /home/Common/pyPacks is in github, as is the code for the django project. I have multiple computers in different locations. If I fire up a computer and want to work on the django project or my common library, I must *remember* to git pull, just as when I finish I need to git push. Keeping the computers in sync is not a big challenge. It is true that I am working on these alone, but I assume collaborative tools are available and robust. – Rick Graves May 19 '19 at 06:39
  • After I did git pull on my web server and set PYTHONPATH in the OS and Apache2, python for the django project could not find the common library files -- PYTHONPATH works in development but not in production. – Rick Graves May 19 '19 at 06:46

0 Answers0