Vendor files

[GitHubCaps]

@MicroJoe in reference to #1556, #1557, #1558

I realize that you and others would like the vendor files treated as separate packages, but for this project, I believe about the best we can do is put them in their own directory and updating from time to time.

For example, the most recent code for the text plugin no longer supports 2, so we have to patch it on our end, not to mention that the author of the plugin, @HomineLudens, added his own code to ttf.py

As far as python_utils and stl (same author WoLpH), we only need a portion of the code and it is better that we have finer grain control to strip out and only implement what is necessary.

As for svg that's maintained by @tatarize, their code seamlessly works and they do their own pull requests here (not to mention others here).

Anyways, in short, I believe other than separating them in the project and aside from updating them, they should be left alone, otherwise, when things on their end go wrong for us, we will have to wait for them to fix it. I don't know about you, but that's a deal breaker for me and I am sure others too.

@Harvie I already have all of the 3rd party libs split from the lib directory and removed everything nonessential. In mine, I simple put the 3rd in a lib3 directory to keep it organized (alphabetically), but I suppose vendor would be more fitting.

[tatarize]

Part of the reason for svg to be in its own file was that I previously dropped Python2 support, and restored it for a version to make sure to update the code here with 2/3 compatible code. I'm unsure where this project is in the py2 -> py3 space but directly including the single file seemed like the best option there, since when I got the code to a more stable place it wasn't going to include py2 support, so I restored support for a version and directly included the library here, again, in its much more finalized state.

It could easily be moved off as a separate package and if you required the right package from pypi still support 2/3. But, the version here is basically intended just for this project since I dropped most py2 support at EOL, and just restored it for this project (1.4.2 ~ Christmas 2020) since I said I would swing back around when I finished up the major code and had at that time. The code apparently even adopted a to_zip utility refactoring for some such reason.

All the version changes since 1.4.2 to the current 1.6.8 have been fairly minor (underlying color structure ARGB->RGBA in 1.5.x and a backwards compatible SVGText -> Text and SVGImage -> Image shift in 1.6.x), but very minor things like correct values for some degenerate shapes, or bounding-boxes able to take with_stroke values). So there really isn't much reason this code would need to change, probably ever. Unless you hit some rare bug like the display:None being css and not svg thus case insensitive and should be treated identically to display:none issue, or the less robust dataurl parsing (which you don't use anyhow). These are all extremely minor and the included code should just work as a stand-alone thing for the vast majority of cases.

1. Very minor updates going forward.
2. No python 2 support outside of version 1.4.2.
3. The library is intended to just permit pasting the file into existing project, it seemed like a very reasonable methodology to me.

[GitHubCaps]

@tatarize Thanks, for the present!

But, the version here is basically intended just for this project since I dropped most py2 support at EOL, and just restored it for this project (1.4.2 ~ Christmas 2020) since I said I would swing back around when I finished up the major code and had at that time. The code apparently even adopted a to_zip utility refactoring for some such reason.

As far as the to_zip (more aptly named lzip or list_zip),
it is there for compatibility. In Python 2, you don't need list because it is already a list. In Python 3, zip now returns an iterator that needs list to access, modify etc. We can simply add list to Python 3, but for 2, your actually putting a list inside another list. Also, I haven't checked to see if it is even necessary for svg_elements, I believe @DodoLaSaumure put it there because it was, but not sure at the moment.

# Convenience functions instead of try/except 
if python >= 3:
    def lzip(*args, **kwds): return list(zip(*args, **kwds))
else:
    def lzip(*args, **kwds): return zip(*args, **kwds)

What I have done for svg_elements at the moment is just placing it (and the other 3rd parties) in its own directory bCNC/lib3/tatarize/svgelements/svg_elements.py. This way I believe gives credit and you know at a glance where it comes from. I placed a README.md in bCNC/lib3/ to be used to reference the packages there. Plus, having a directory structure for adding licenses, etc outside of bCNCs main lib directory would be better imho.

Example of ttf from pyglet, bCNC/lib3/pyglet/font/ttf.py, minus the tree master!
It is only used by the text plugin, which is also 3rd party (actually, the plugins directory is basically a 3rd party directory).

Part of this is for making easier comparisons in the future, if needed. The other is to provide a place for standalone libraries for the future, before it becomes anymore of a mess.

[gagath]

Hi,

Anyways, in short, I believe other than separating them in the project and aside from updating them, they should be left alone, otherwise, when things on their end go wrong for us, we will have to wait for them to fix it. I don't know about you, but that's a deal breaker for me and I am sure others too.

This does not seems true to me: you can always go back to the latest working version. You could also lock your versions of the dependencies even if they are external, by specifying a concrete version (1.2.3.4) instead of a compatibility wildcard (1.2.*).

This discussion is a classic dilemma between vendoring making it easier for end-users (?), and making it harder for distribution maintainers.

Anyways, please know that in the Debian port that I am maintaining (yes, you can apt install bcnc 👏), all of dependencies have been un-vendored and use the dependencies themself quite fine. Latest python-svgelements is used. We do not need Python 2 support as it has been EOL’ed (and it is almost removed from Debian IIRC). This allso means that in case of security hole in one of the libraries, bCNC will not be vulnerable because the libraries will be patched within Debian.

PS: I do not understand why you have cited #1557 here, it should be merged because it references dead code and is not related to this discussion.