@@ -153,3 +153,92 @@ The command line equivalent for the model is...
153153
154154 The reason it's called ``arg `` right now is because the parsing of the command
155155line came first and the argument is stored there when it's not nested.
156+
157+ setup.py
158+ --------
159+
160+ There are various ``setup.py `` files throughout the codebase, one for the main
161+ package, one for each plugin, and one in ``skel/ ``. There are also
162+ ``setup_common.py `` files.
163+
164+ Checking For Development Version
165+ ++++++++++++++++++++++++++++++++
166+
167+ You might have asked yourself, what is this thing?
168+
169+ .. code-block :: python
170+
171+ INSTALL_REQUIRES = [] + (
172+ [" dffml>=0.3.3" ]
173+ if not any (
174+ list (
175+ map (
176+ os.path.isfile,
177+ list (
178+ map (
179+ lambda syspath : os.path.join(
180+ syspath, " dffml.egg-link"
181+ ),
182+ sys.path,
183+ )
184+ ),
185+ )
186+ )
187+ )
188+ else []
189+ )
190+
191+ This code is needed because ``python `` will use extracted versions of packages
192+ over development versions if they are installed.
193+
194+ ``pip `` will download and extract a package (thereby installing it) if it sees
195+ it in the ``INSTALL_REQUIRES `` list. This wrecks havoc with our development
196+ workflow.
197+
198+ For example, when we put the main package, ``dffml `` in the ``INSTALL_REQUIRES ``
199+ list of a plugin, ``pip `` will go off and download the appropriate version from
200+ PyPi and extract it to a place Python searches for packages. Now when we run
201+ anything we'll end up using the version ``pip `` just installed instead of the
202+ version we're developing on locally.
203+
204+ The solution to this is to add the above code block to ``setup.py `` files. The
205+ innermost list is ``sys.path ``, which is all the places Python is going to look
206+ for packages when there is an ``import `` statement. We use ``map `` to apply a
207+ function to each directory in ``sys.path ``. The map will take the directory name
208+ and add ``dffml.egg-link `` to it. We add this because when you install something
209+ in development mode (``dffml `` in this case) ``pip `` creates this ``.egg-link ``
210+ file. In the file is the path to the source code you're working on. Therefore,
211+ if that file exists, then the package is installed in development mode. The next
212+ ``map `` then checks if any of the file paths generated by the previous ``map ``
213+ exist. If ``any `` of them exist, then there is a ``.egg-link `` file somewhere in
214+ Python's search path, which means the package (``dffml `` in this case, hence the
215+ ``dffml.egg-link ``) is installed in development mode.
216+
217+ If the package is installed in development mode, then we don't want ``pip `` to
218+ install it from PyPi, since that would cause the development version not to be
219+ used.
220+
221+ Notes on Various Subsystems
222+ ---------------------------
223+
224+ DFFML is comprised of various subsystems. The following are some notes
225+ that might be helpful when working on each of them.
226+
227+ Working on ``skel/ ``
228+ ++++++++++++++++++++
229+
230+ The packages in ``skel/ `` are used to create new DFFML packages.
231+
232+ For example, to create a new package containing operations we run the following.
233+
234+ .. code-block :: console
235+
236+ $ dffml service dev create operations dffml-operations-feedface
237+
238+ If you want to work on any of the packages in ``skel/ ``, you'll need to run the
239+ ``skel link `` command first fromt he ``dev `` service. This will symlink required
240+ files in from ``common/ `` so that testing will work.
241+
242+ .. code-block :: console
243+
244+ $ dffml service dev skel link
0 commit comments