Thank you for the explaination Kale, I didn't fully understand what you 
meant before.

I'm not terribly familar with setuptools to be honest. My main concern is 
that pyglet remains able to be run by dropping it's folder into a project, 
and not be reliant on setup.py being run for installation. That's a pretty 
big strength, and how I personally use pyglet in my projects.

Other than that, I wonder what other codecs this could be useful for down 
the road.


On Wednesday, February 1, 2017 at 3:13:34 PM UTC+9, Kale Kundert wrote:
>
> What I was thinking was something like this: 
>
> First, advertise a "pyglet.codecs" entry point in setup.py.  List all the 
> codecs 
> that are currently included with pyglet as entry points.  This is nice 
> because 
> first-party and third-party codecs will be handled in the same way: 
>
> def setup( 
>         ... 
>         entry_points = { 
>                 'pyglet.codecs': [ 
>                         'png = pyglet.image.codecs.png', 
>                         ... 
>                 ] 
>         } 
>         ... 
> ) 
>
> Then, replace pyglet.image.codecs.add_default_image_codecs() with 
> something like 
> this: 
>
> def add_default_image_codecs(): 
>         from pkg_resources import iter_entry_points 
>         for entry_point in iter_entry_points(group='pyglet.codecs'): 
>                 codec = entry_point.load() 
>                 add_encoders(codec) 
>                 add_decoders(codec) 
>
> Now third-party modules can define custom codecs just by adding 
> entry-points to 
> their own setup.py files: 
>
> # Let's say this is the 'pyglet_aseprite_plugin' package... 
> def setup( 
>         ... 
>         entry_points = { 
>                 'pyglet.codecs': [ 
>                         'aseprite = pyglet_aseprite_plugin', 
>                         ... 
>                 ] 
>         } 
>         ... 
> ) 
>
> All a hypothetical user has to do is: 
>
> $ pip install pyglet_aseprite_plugin 
>
> When add_default_image_codecs() is called, setuptools/pkg_resources will 
> tell it 
> about every 'pyglet.codecs' entry point installed on that system, no 
> matter 
> which package they come from.  So first-party and third-party codecs will 
> get 
> loaded in the same way.  This wouldn't be a very big change to pyglet all 
> told, 
> but it would be nice for plugin developers. 
>
> The documentation for this stuff was annoyingly hard to find, so here are 
> some 
> links if you want more information: 
>
>
> http://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins
>  
>
> http://setuptools.readthedocs.io/en/latest/pkg_resources.html#entry-points 
>
> I don't have any particular interest in aseprite, but I might be able to 
> make a 
> pull request for the plugin architecture over the weekend if there's 
> interest in it. 
>          
> -Kale 
>
> On 01/31/2017 05:20 AM, Benjamin Moran wrote: 
> > I'm not quite sure how it could work. The decoders/encoders are actually 
> part of 
> > the pyglet.image module. The pyglet.image.base basically scans in all 
> available 
> > units from pyglet.image.codecs, depending on the platform. The 
> pyglet.resource 
> > module simply loads in whatever images the pyglet.image module supports. 
> > 
> > So, to make this work, you would need to have something like 
> > "pyglet.image.add_decoder", and then make sure you add your decoders 
> module in 
> > before doing any pyglet.resource.reindex() calls. This all seems a 
> little 
> > awkward to me, with the way things currently work. 
> > 
> > Maybe the image module could automatically check and load applicable 
> modules 
> > from pyglet/image/codecs, without first having to define them in 
> > pyglet.image.base. This would mean developers could just copy in the 
> appropriate 
> > module to this directory in their codebase, This wouldn't really work 
> for 
> > projects that install pyglet from pip, however. 
> > 
> > 
> > On Tuesday, January 31, 2017 at 7:05:21 PM UTC+9, DXsmiley wrote: 
> > 
> >     This sounds too niche to warrant including in pyglet itself. 
> > 
> >     I think that Kale's point is interesting. Allowing third-party 
> modules to 
> >     add additional decoders to pyglet.resource could be useful. 
> > 
> > -- 
> > 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] <javascript:> 
> > To post to this group, send email to [email protected] 
> <javascript:> 
> > <mailto:[email protected] <javascript:>>. 
> > Visit this group at https://groups.google.com/group/pyglet-users. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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 https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to