search

klahnakoski / mo-dots

Attribute accessors for dicts
Mozilla Public License 2.0
6 stars 3 forks source link

mo-graphs #3

Open bitnom opened 4 years ago

bitnom commented 4 years ago

I love graphs. Maybe some mo hypergraph action as a separate package. what think?

klahnakoski commented 4 years ago

I agree a package of graph tools would be nice; From time to time I find myself implementing some graph algorithm, or taking time to find it. Although, I am not the person to be assembling the library I do not use graph algorithms enough.

Before you make a stand alone package (which comes with deployment delays and version synchronization problems), there are some steps you can take to prepare, and be less work:

  1. Separate your proposed library code into vendor/mo_graphs (using the export PYTHONPATH=.:vendor) This will ensure your project code has the correct imports.
  2. Synchronize library code between multiple projects: If you find your library will be useful in other projects, include vendor/mo_graphs code in those projects too; You do not do this by copying code, rather synchronizing with SVN The good thing about this setup is you can change/upgrade your library code while working on your current project, and ensure your project is passing tests, without breaking your other projects. (the initial versions of your library will change often) At the same time, you are increasing your library test coverage because each project will use some different aspects of your common library.
  3. Make a formal package - Once you use your library in multiple projects, and it does not change too much, and you find yourself writing a test suite for your library (not just relying on tests from the projects that use your library) then you can release a package, and update your various projects to use that package (remove the vendor library and add a install_requires=)

You can see step2 in action here: https://github.com/mozilla/Bugzilla-ETL/tree/dev/vendor These directories are synchronized with the libraries of the same name from time to time: In theory I can now remove them, and replace with package requirements. This project was the brirth place of mo-dots; if you hunt through the history (and through all the massive renames), you will see how it changed over time; it even belonged to another library before splitting out on its own. Here is the earliest version: https://github.com/mozilla/Bugzilla-ETL/commit/2166855e3ff52a421071dbc733e09268be6f2d27#diff-fd4ca02e8212acd625be3695505a33d400d742ea1806e5b001982d5b14099298

Tell me what you think of step 2: Despite my success with using SVN synchronization between projects, I have been unable to convince others it is a good way to manage code.

bitnom commented 4 years ago

Interesting. I haven't used svn since git sort of invaded everything but I'll give the methodology a try.