<marcan>
whitequark: btw, do you have any particular guidelines on applets you want/do not want in glasgow?
<marcan>
I ask this because there is basically no reason for me not to use it for all kinds of FPGA experiments, possibly things that will eventually be standalone boards but for which components can be validated in Glasgow
<marcan>
e.g. I want to make an I²S->ADAT encoder, this could be validated as an 8-channel ADAT playback applet and an I²S sniffer/capture applet, and then combined into one design that doesn't use USB (would that be useful as its own applet?)
<marcan>
I imagine at some point it would make sense to support applets not hosted within the glasgow codebase itself, and also be able to enumerate applets without running much if any code or pulling in their dependencies
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
marcan: i want almost all applets that perform a function someone may be interested in by using solely publicly available components
<whitequark>
the other criterion is, is code good enough?
<whitequark>
re: hosted not within glasgow itself, that was the plan from day 1
<whitequark>
but it's not entirely clear how to make these fit nicely into python
<marcan>
whitequark: in principle you only need to enumerate the first level before invoking the code, right?
<marcan>
so distutils/whatever has all that entrypoint stuff that can be used for plugins afaik, or you could use some other metadata system
<marcan>
I guess [tool|run] --help only need a description string to be available without loading the module
<marcan>
sorry, s/distutils/setuptools/
<whitequark>
marcan: there's quite a bit of stuff going on during discovery
<whitequark>
the CLI is looking at required pin counts, required revision, preview status...
<marcan>
we can define our own metadata in a json file (or whatever floats your boat) and add it as a setuptools extension
<marcan>
as long as it's sattic
<marcan>
*static
<marcan>
basically just avoid actually importing all the applets
<whitequark>
i'm not happy about anything that makes the simplest applet not a single file
<whitequark>
because a lot of the time, the effort to write a new applet is borderline too high for myself
<whitequark>
new idea
<whitequark>
sha512 the applet file, cache metadata, don't load it if the cache is the same
<marcan>
well if it's going to be python packages you need a setup.py file and a typical module structure, no?
<marcan>
I mean glasgow could just have a new_applet thing that makes the directory structure for you
<whitequark>
python package per applet? fuck no.
<marcan>
not per applet, but per group of applets
<marcan>
you could bundle as many as you want
<marcan>
but I mean if code is going to live outside the glasgow repo, it's either going to have setup.py or some other way of specifying dependencies, or we need to reinvent all that shit ourselves
<marcan>
of course built in applets would still live in the main codebase
<whitequark>
we're going to have to reinvent something anyway
<whitequark>
to have the `glasgow cli` command discover 3rd party code
<marcan>
setuptools already has a mechanism for discovering 3rd party code
<whitequark>
hm
<marcan>
we just need to add some metadata structure with our own junk if we want to be able to load it without importing anything
<marcan>
it's literally the same thing glasgow already uses for the cli command
<marcan>
entry_points={
<marcan>
"console_scripts": [
<marcan>
],
<marcan>
},
<marcan>
"glasgow = glasgow.cli:main"
<whitequark>
oh i see
<marcan>
we just do "glasgow_tool": [ "i2s-capture = marcansuperglasgowpackage.i2s_capture:I2SCaptureApplet" ] or whatever
<marcan>
or glasgow_applet
<whitequark>
that's pretty good
<marcan>
and you can query for all packages implementing a glasgow_tool or a glasgow_applet
<marcan>
we'd just need to add some custom magic (this is supported) to add e.g. a json manifest as well, as a sidecar, if we want to be able to pull info without importing modules
<marcan>
the json could be generated from the modules themselves
<marcan>
it would just be a setup.py-time cache
<marcan>
and of course since applets will depend on glasgow itself, we can have a setuptools wrapper that makes life easy for module writers
<whitequark>
ok, gotcha. let's discuss the details sometime else, because i'm having an absolutely horrible morning
<marcan>
sure, np
<marcan>
I'm actually busy too
<marcan>
just brought this up because it wandered into my brain :)
<whitequark>
yeah, the entry points knwledge is very useful