On Thu, Oct 24, 2013 at 12:52 PM, "Juan J. MartÃnez" <[email protected]> wrote: > On 24/10/13 10:33, anatoly techtonik wrote: >> pyglet codebase has copies of libraries such as pypng that are >> maintained elsewhere. It is actually a good thing, because thanks to >> that you can just unpack and run without installing. However, sometimes >> these libs should be synced with upstream, and it is convenient to check >> all of them at once. The problem is to locate those libs. For example, >> pyglet.font.win32fontquery is such lib, and pyglet.image.codecs.pypng >> too, but they are located just as usual pyglet modules. >> >> To make it convenient to work with external libs that are present in >> pyglet codebase (upgrade, test, view), I propose to move such modules to >> pyglet.upstream. >> >> +1 / -1 ? > > I think the problem is not really locating the libraries but doing the > "sync" itself. It's not just copying files and that's all, we need to > run the tests and check everything works as expected, and I don't know > if we have some local changes to these external libraries.
Right. The main feature of pyglet.upstream (pyglet/upstream) is that while being a Python path, it may also contain README for developers that describes how to handle this stuff properly, what patches are applied, what upstream bugs are fixed, etc. > Can we automate this without moving the libs to a different location? It can be automated, but you have to place scripts somewhere, and there are not many places where people can find them. I have a dozen of projects and I don't remember layout of any their scripts inside. More than that - I don't want to remember layout of each of them. But I would appreciate a common convention to handle externally included libraries. upstream subpackage is also a place (namespace) for licenses and credits to those. > I don't want to change the API, so it's fine to place the files in a > more specific directory, but the API should be the same it is right now. I am sure it is possible to proxy requests - if I am not mistaken, pyglet already does some lazy import magic to avoid importing all libraries at once. So, a simple redirect to fetch symbol from another package is fairly possible. > To be honest I'd love to move these external libs into dependencies, we > are effectively "forking" upstream libs and no surprise maintaining them > is a hassle. You're wished are contradicting. =) You need to choose between "self-contained" or "with external dependencies". For me former outweighs the latter significantly > Besides these "dependencies" could even be optional, pypng is a fallback > mechanism if you don't have a better option already installed in your > system, and I guess same thing applies to pyglet.font.win32fontquery > (you may not use it? I'm a little bit uninformed regarding this one). Without win32fontquery you will not be able to check if a particular font exists on Windows system (or query all fonts that exist). It can be a to load *exact* font required, so this module can help to do this manually. https://code.google.com/p/pyglet/issues/detail?id=678 > But I'm not sure if we can do it: > > - pyglet is currently self-contained, for distribution this is gold! > - win32fontquery is not on PyPI, is it? Not on PyPI, because it is a copy of more general lib https://bitbucket.org/techtonik/fontquery To be released on PyPI it needs Linux and MacOS support. -- anatoly t. -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/groups/opt_out.
