OBEX on GitHub
Rayman
Posts: 13,859
I think OBEX is moved to GitHub, right?
https://github.com/parallaxinc/propeller/tree/master/libraries
Seems there's an "official" folder and a "community" folder.
Also a P1 and P2 folder.
Appears that anybody can create new folders in community and put code there...
Might be a good place for P2 version of FemtoBasic...
https://github.com/parallaxinc/propeller/tree/master/libraries
Seems there's an "official" folder and a "community" folder.
Also a P1 and P2 folder.
Appears that anybody can create new folders in community and put code there...
Might be a good place for P2 version of FemtoBasic...
This discussion has been closed.
Comments
Then you push your changes back and create a pull request which just merges your changes back into the repository even if someone else has made other changes to the repository while you were working on your changes. Even though it looks like you pushing the hole repository your are only pushing your changes.
Mike
Git folklore: https://xkcd.com/1597
Maybe it would be possible for somebody good at HTML coding to write a convenient front end for GITHUB. If we put a standardized readme file in every sub-folder of OBEX the front end could automatically scan those files and create a nice "menu" of whats available with links for easy download.
That's actually a good direction to consider. A simple frontend website that exposes the github content in a way similar to the old OBEX would be fantastic, and probably not that hard for someone who knows/does web coding/dev.
That would let us keep the versioning and collaboration of git/github but have a easier/simpler site for most people to use for accessing the content.
Mike
Creation/modification dates can be obtained automatically from the files and the GIT history. Same for language which can be found out by scanning file extensions. The only really necessary fields IMHO are:
1) a category under which the entry should be listed
2) a useful description of the content: purpose, what does it, what is necessary to get it to work
This has several advantages:
1. Users don't have to pull the entire OBEX just to get one item out of it.
2. The repository description is searchable, both in github at large and within the search function of an organization page (try typing "SimpleIDE" in the search box at https://github.com/parallaxinc).
3. Contributors can create new submissions under their own account, then Parallax can choose to fork it to "include" in their curated list.
4. This approach should require less administrative overhead. (For instance, no need for doing the whole fork-pull-branch-update-push-PR routine just to update OBEX code you had submitted in the first place.)
(note: if concerned about having too many repositories listed under parallaxinc, create another organization (e.g. "obex") for that purpose. parallaxinc repositories can also be forked under the other organization to keep things all in one place for the end-users.)
Edit: this does not, however, provide a "directory" like the current OBEX. Even so, I think this approach is a better way to organize everything. I'm sure we can figure out how to add a directory back into it.
There are articles on using github as a CMS system via the API. I think this is the path to consider going down. I don't think we need to mess with the readme files, we can just create/update/store the data needed in the repository along with the source content.
The readme files could be automatically updated as well for people that prefer to go direct to the git/github repo directly, but they don't need to have anything for the CMS system.
As for github APIs, I also wonder what it would take to use their new "Packages" functionality. At a glance, I can't tell if it only works for specific packaging systems that they support, or whether we could create a packaging system for OBEX items. Then users just do something like:
That would be neat...
Git and GitHub are tools for cooperative software development and version control.
None of this applies to a OBEX replacement
Mike
That said, and I'm sure some of it is personal bias - I think it's easier to just download an entire repository, and if I'm looking for something, I have it locally already and can search with PC-based tools I'm familiar with, rather than having to wait for possibly slow or downed servers. For users of a library/repo, "git clone <repo>" to get the repository and periodically "git pull" to update it are about the only things you need to know.
i dont see why that zip file couldnt have included a rev number and date....with a simple list of past revs.....if u didnt let information get lost...the original author would have permissions to up the rev level...
its not a very hard website to design sn operate.....github is kinda complex looking and all the files become the owned by its operator Microsoft...we all now thier revision history
all info in one spot
I've been working on a web application that will hopefully help those out that don't like using GitHub. I personally prefer GitHub, but I also think it would be unfortunate if the community starts splitting up were everything is stored.
This project will give a nice (well, I'm an engineer, not UI guy lol) frontend that will allow searching of the GitHub OBEX, as well as other repos people might use, and downloading zips of the objects. In the future I plan to also add the ability for those who don't like git to upload new/updated objects and the web app will take care of creating a pull request to the OBEX for them. This isn't meant to replace the OBEX at all, just facilitate everyone using it.
Looking forward to seeing your results.
I don't know if it's possible to do this for git repositories hosted on Github, but for repos hosted on machines that you control, you can add script plugins to reject pushes based on the content of the push, and there are already various easily configurable plugins that do all this for you. So, for example, you could set it up to allow users to only push commits to the main branch if those commits only modify their own projects, while still allowing users to push whatever they want to their own private branch, which can be merged into the main branch by the project owner or an admin. Or, there could just be a separate repo for each project, which would make permissions much simpler.
I think the best thing to do would be for Parallax to host something themselves that looked like the OBEX's web interface, but that actually used a separate git repository to store each project. People who don't want to be bothered with git don't have to know that it's really a git repo under the hood, but people who prefer git can interact with their project through git. Normally, the website would host the git repo itself, but those who prefer to use git directly could have the option of manually giving the website a URL to an externally repo hosted somewhere else, say on Github or Gitlab, in which case it will just act as a frontend (but probably not allow edits through the web interface for a foreign repo).
good faith programming..to owned by microsoft
Yes, there's that too - why use another Microsoft service when you could just as easily host your git repositories in dozens of other places?
I think in this case, having it be hosted on a reliable service (regardless of your opinion of the owner of said service) is the easier option for them. I also suspect that they need the communities help in building a frontend and maintaining it.
Whether Parallax hosts their own git servers or uses GitHub, people seem to want a frontend to it, so why add creating a new backend to the bill?
Edit: I missed the GitLab comment, which is also a great option. Having said that, I would still say GitHub is less work for Parallax than running their own GitLab instance.