Shop Learn
OBEX on GitHub — Parallax Forums

OBEX on GitHub

RaymanRayman Posts: 11,932
edited 2020-04-17 15:34 in Propeller 2
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...
«13

Comments

  • It looks like the various versions of FemtoBasic for P1 are all there. The P2 community folder looks like the appropriate place for FemtoBasic for P2 once it's a bit further along.
  • I've already used GIT but I'm new to GITHUB. I've just read this guide of how to contribute. Is it really necessary to pull the complete repository or is it possible to create subfolders? OK, at the moment the whole propeller tree is empty except for the readme files so it should be no problem. But as the archive grows having to handle it as a whole bundle might slow things down considerably...
  • You pull the hole repository and then you make changes by adding your project to the repository.

    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
  • RaymanRayman Posts: 11,932
    Really? You do the whole repository? Interesting... I wouldn't have thought it worked that way...
  • There are some tricks to pull less (e.g. look for `git clone --depth=1`) but storage is no topic today and on later pulls you only fetch the differences, so it'll be fast. If bandwidth is a problem, make a backup of fresh clones before playing too aggressively with it.

    Git folklore: https://xkcd.com/1597
  • Roy Eltham wrote: »
    I understand and use git (mainly github) quite a lot, and I agree it's not a good OBEX substitute.

    The main issue for me is that it's painful to just get the one or two things you want. It's trivial to get the whole thing, but getting a single source file requires navigating to the file and then viewing it raw and saving it manually.
    There's probably a command line way to grab just the one or few files you want, but it's going to be something non-obvious and still require setup commands to connect to the repo and whatnot.
    Agreed. GIT is a great tool for developpers especially for open source projects where multiple programmers are involved. But it overstrains joe random user who just wants to download a little piece of code.

    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.
  • ManAtWork,
    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.
  • It looks like if you read all the README.MD files they contain By:, Language:, Created:, Modified: and some text that could be read in and maybe presented along with a link to where that README.md came from.

    Mike
  • Yes, that was the idea. I'd try to keep the required tags in the readme files to a minimum. Too much information always comes with the risk of forgetting to update it when modifications are made.

    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
  • SeairthSeairth Posts: 2,474
    edited 2020-04-25 21:39
    Actually, there's a way that this could be done right now with github: create a repository per OBEX entry.

    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 ways to have repos in repos...
  • github has a pretty extensive web/REST API that can be used to do pretty much anything with your repositories.
    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.
  • I agree that using the REST API is a good idea for integrating into the IDE or other tools. But wouldn't it make more sense to at least start by using the stock GitHub capabilities? Regardless of using the API, I think it's a bad idea to try to maintain the entire Propeller ecosystem inside a single repository, especially considering that most contributors are not git-savvy (nor likely to become git-savvy).
  • SeairthSeairth Posts: 2,474
    edited 2020-04-25 22:44
    Roy Eltham wrote: »
    github has a pretty extensive web/REST API that can be used to do pretty much anything with your repositories.
    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:
    obex install serial
    
  • RaymanRayman Posts: 11,932
    Maybe the new Propeller Tool could somehow be connected to GitHub...

    That would be neat...
  • "If you have a Hammer, everything looks like a Nail"

    Git and GitHub are tools for cooperative software development and version control.

    None of this applies to a OBEX replacement

    Mike
  • why did obex go obsolete?
  • msrobots wrote: »
    "If you have a Hammer, everything looks like a Nail"

    Git and GitHub are tools for cooperative software development and version control.

    None of this applies to a OBEX replacement

    Mike
    I'm not sure I agree entirely. We may not have many collaborative projects but version control and the ability to receive pull requests could be helpful. As someone pointed out though, having one repository per submission would work better than a single repository containing everything. There could still be a master repository that included all of the others as submodules though.

  • That's what I do with my drivers (though not the submodules - would love to use those instead but I think it makes each submodule a subdirectory)...it's kind of a pain to maintain more than one copy of each: all of the separate repositories, then once it's "good enough", I copy it to the library-formatted repo, but I figured it makes it a bit easier for someone else to download.
    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 think the way u could do a quick search and get a nice zip file worked great....


    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
  • actually...past revisions should be included in the newest revisions zip file

    all info in one spot
  • I wasn't originally going to mention anything until I had something more to show (only started on it about a week or two ago on my free time), but I also don't want to reinvent the wheel if others are doing something already.

    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.
  • Sounds great emiljt!

    Looking forward to seeing your results.
  • ElectrodudeElectrodude Posts: 1,438
    edited 2020-04-27 18:27
    I agree that it would be best to have a web interface that can hide the fact that it's really Git underneath, but I think it should be more tightly integrated with the git server.

    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).
  • why ask for demos to put them on github...wont there be license infrigment

    good faith programming..to owned by microsoft
  • overhere wrote: »
    why ask for demos to put them on github...wont there be license infrigment

    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?
  • Please take a moment to read https://help.github.com/en/github/site-policy/github-terms-of-service (it's written in very plain language).
  • ElectrodudeElectrodude Posts: 1,438
    edited 2020-04-29 17:49
    Sorry, yes. Of course you still own anything you host on Github. My point is that it's not necessary to use another Microsoft service when there are perfectly good alternatives - some of which you can even host yourself. It should be easy for Parallax to set up and host their own instance of GitLab or Gogs or something, and then make a new OBEX that's really just a frontend for it.
  • I don't think I was call it "easy" for Parallax to do. They'd have to setup and pay for hosting of it, and have someone to build and maintain it.
    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.
  • emiljtemiljt Posts: 45
    edited 2020-04-30 00:36
    I actually like that Parallax puts stuff on GitHub. Its very well established, works great, and its pretty much the standard when it comes to hosting open source code. GitHub also comes with a lot of useful tools most open source projects are accustom to like issue tracking, builds, etc.

    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.
This discussion has been closed.