Repository navigation
how do we associate contribs #25
Description
Activity
I propose to have this modules on an independent repo to isolate it from
the MicroPython core.(Yes, I know, it seems I'm a bit obsesed with having a lot of repos, but I
believe they can help to organice the code better... :-) )2014/1/1 Neon22 [email protected]
As we add people, they will want to write python modules that work in
micropython. (I know I do :))
We could have a contrib folder but it'd be a foodfight for changes
probably.-
If we don't have a contrib folder and instead allow people to make
new projects that will work on micropython - how do we want everyone to be
able to find them ?
2.recommend they start with mupython- or ... ?
3.I think we should have a pyb module stub which people can include to
get their projects working.
Initially with only a few definitions (pyb.led, pyb.i2c,..)but
eventually stabilising to some release as the exposed interface.
Where should this go ?
How should it be handled ?
If we can work out how to do it - I will doc in Wiki so people can get
started...—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25
."Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux-
I agree; putting the associated modules on a different repo base allows not
only better organization, but the ability to restrict any potential fallout
from, e.g., code releases that might inadvertently break the modules.
Also, any module authors would then be responsible for maintaining their
own modules, rather than having to divert the attention of the main
codebase contributors.Organizationally, I think it makes sense that way.
-- Dr-Syn
On Wed, Jan 1, 2014 at 2:00 PM, Jesús Leganés Combarro <
[email protected]> wrote:I propose to have this modules on an independent repo to isolate it from
the MicroPython core.(Yes, I know, it seems I'm a bit obsesed with having a lot of repos, but I
believe they can help to organice the code better... :-) )2014/1/1 Neon22 [email protected]
As we add people, they will want to write python modules that work in
micropython. (I know I do :))
We could have a contrib folder but it'd be a foodfight for changes
probably.- If we don't have a contrib folder and instead allow people to make
new projects that will work on micropython - how do we want everyone to
be
able to find them ?
2.
recommend they start with mupython- or ... ?
3.I think we should have a pyb module stub which people can include to
get their projects working.
Initially with only a few definitions (pyb.led, pyb.i2c,..)but
eventually stabilising to some release as the exposed interface.
Where should this go ?
How should it be handled ?If we can work out how to do it - I will doc in Wiki so people can get
started...—
Reply to this email directly or view it on GitHub<
https://github.com/micropython/micropython/issues/25>
."Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-31431197
.- If we don't have a contrib folder and instead allow people to make
A new repo for contributed modules/drivers/libraries does sound like the better way of doing things. I can make repos under the micropython organisation, and give push rights to people who want to maintain them.
Do we agree the consensus is two fold:
- Create a new project under existing micropython project. (like pyboard)
- Call it something like - user contributed modules.
- Allow github users to add folders to it containing code written for the micropython environment.
- clearly currently code would be predictive...
- Advocate if people write modules in their own repositories - that they use the naming convention of micropython-foo for their projects so others can find them.
If so then I'll write that up in the wiki - and maybe Damien can make the new project or...?
and we can close this issue ?It can really start more lean and mean - people start writing modules in their own repos, use whatever media to announce them (ultimately, with more an more voices requesting forum on micropython.org), once it's proven that a module does something useful and well-maintained, it can be accepted into common repo (but why is they would be viable on their own?)
People who want to do more right away, can start paving road for module submission to
https://pypi.python.org/pypi (do test submissions, do PR with PyPi maintainers, write pip-like tools for uPy, etc.)It's ultimately up to Damien, but even "Allow github users to add folders to it" will require effort on his side, while there're enough effort to put into uPy and pyboard already... And that's without questions of maintenance of such contributed modules, supporting users on issues with them, etc.
Based on your posts, I propose people using the micropython-* scheme on
their projects names to show that's something related/compatible with
MicroPython, and when it gets enough mature, and them as git submodules to
a central micropython-contrib-packages repo.Send from my Samsung Galaxy Note II
El 05/01/2014 13:11, "Paul Sokolovsky" [email protected] escribió:It can really start more lean and mean - people start writing modules in
their own repos, use whatever media to announce them (ultimately, with more
an more voices requesting forum on micropython.org), once it's proven
that a module does something useful and well-maintained, it can be accepted
into common repo (but why is they would be viable on their own?)People who want to do more right away, can start paving road for module
submission to
https://pypi.python.org/pypi (do test submissions, do PR with PyPi
maintainers, write pip-like tools for uPy, etc.)It's ultimately up to Damien, but even "Allow github users to add folders
to it" will require effort on his side, while there're enough effort to put
into uPy and pyboard already... And that's without questions of maintenance
of such contributed modules, supporting users on issues with them, etc.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-31602640
.At the moment almost no one has a pyboard, so it's not possible to test contributed modules. And I don't want to have thousands of lines of untested code! (Yes, people might want to contribute modules to the unix port, and can test those, but unix is not the priority right now.)
Let's start simple. People can use their own github repository to host their modules, and, when they have been tested and shown to be useful, they can be merged into the micropython repository.
I would have micropython repository as small as possible, and fetch user
contributions and extensions on a PiPy or NPM like application. AFAIK you
can deploy your own PiPy repositories and also on Python 3.x they have
improved and unified a lot the packagement system...2014/1/20 Damien George [email protected]
At the moment almost no one has a pyboard, so it's not possible to test
contributed modules. And I don't want to have thousands of lines of
untested code! (Yes, people might want to contribute modules to the unix
port, and can test those, but unix is not the priority right now.)Let's start simple. People can use their own github repository to host
their modules, and, when they have been tested and shown to be useful, they
can be merged into the micropython repository.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-32725305
."Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux- added a commit that references this issue
on Oct 21, 2016 - added a commit that references this issue
on Jan 22, 2017 - added a commit that references this issue
on Aug 20, 2020 - added a commit that references this issue
on Sep 11, 2020 - added a commit that references this issue
on Feb 14, 2021
As we add people, they will want to write python modules that work in micropython. (I know I do :))
We could have a contrib folder but it'd be a foodfight for changes probably.
Recommend they start with mupython- or micropython-... ?
Initially with only a few definitions (pyb.led, pyb.i2c,..)but eventually stabilising to some release as the exposed interface.
Where should this go ?
How should it be handled ?
If we can work out how to do it - I will doc in Wiki so people can get started...