use monotonic package from pypi for python 2.7 only about luma.core HOT 12 CLOSED

Not particularly precious about licenses... arbitrarily chose MIT as it seemed the most permissive and the least amount of words. In fact, we probably should double-check ahem what the licenses are of the dependencies that we do use.

from luma.core.

True. Checked them yesterday and all seem to be MIT except pygame; LGPL.

from luma.core.

so let me fix that, and perhaps add bitbang before a new release?

from luma.core.

think i want to hide the make_serial class (__make_serial ?) in the utils, possibly making only the create_device and create_parser as part of the API.

Do you intend to use get_display_types, load_config etc. outside the package?

from luma.core.

@rm-hull see https://github.com/collab-project/luma.cryptocurrency/blob/master/luma/cryptocurrency/console_script.py that imports these utils which allows me to extend the parser with some extra arguments and do things like luma-cryptocurrency --display sh1106 ticker. Note that .cmdline is a module that is a copy of the examples demo_opts, to be replaced with the new core release code.

Why do you want to hide make_serial? I think I have some use for it in some other project (where I parse a config and basically now have a similar if/else statement that picks i2c or spi import).

from luma.core.

fair enough, that seems reasonable

from luma.core.

if you think they could have a better place in the library, I'm also not a big fan of util, too generic, I'm all for it.

from luma.core.

maybe ultimately scratch the util.py module and split out so:

• luma.core.cmdline for all the command line code
• deprecation can probably be removed once we go to 1.0.0
• does there even need to be a monotonic in there any more with #66?

from luma.core.

1. sounds good, let's do that before next release?
2. maybe but I bet there will be more deprecated in the future
3. yes we want to use stdlib version for py > 3.3, package for < 3.3

from luma.core.

I think we should move the command line code to a different package. Otherwise we'll have to release a new luma.core every time a change is made to a child project.

from luma.core.

How about trying it out in core first, and if it becomes a burden then move it out to a separate package?

from luma.core.

Having to put out a new core release when a new feature is added to a sub project sounds like a bad idea IMO but if that maintenance, and putting out new releases, is ok for you than lets do that.

from luma.core.