ReplAPI.it A Simple and Complete Replit API Package

Hi! I don't know if this is what you guys(and by that I mean @BD103, @RayhanADev, and @JBYT27, super sorry for ping! Just needed to make sure people knew what I meant). I made the cycles grabber, and it works if you put in the right username.

I don't know the name for the function, so I just made it getCycles, so one of you guys can change it.

And if you wanna make the error, go ahead, I just think print is tidier and it exits the program without a bunch of other stuff.

Thanks! I'll make more features!

Describe the bug Making a standard request on staging.replit.com just returns the URL https://replit.slack.com/archives/C3AA56MFS/p1622838662154800.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior Running CLASS.collect() returns a dictionary of the data, while running CLASS.collect_raw() returns JSON.

Screenshots

Desktop (please complete the following information):

• OS: ChromeOS
• Browser: Chrome
• Version: Not sure

Additional context This also breaks CLASS.collect(), because it cannot convert text to a dictionary.

Hello, everyone! We have some new people on the repo, specifically @darkdarcool and @JBYT27. Because of this, I would like to highlight the standards for committing to the repo. Let's get started:

Committing Format

All commits should follow Conventional Commits, a guideline followed by the entire project. What does this mean? All commits should be formatted like the following:

<type>[optional scope]: <description>

[optional body / long description]

[optional footer(s)]

Most of the time, Replit only supports a short description. Because of this, you would probably only insert line 1 of that sample. If you are making a commit on Github, then the long description is supported.

What are types?

The types represent what the commit is doing. For instance:

• fix: A commit that patches a bug, but does not add any new features
• feat: A commit that introduces a new type of feature to the code. This does not change anything, only adds on.
• BREAKING CHANGE: (or you could also add an ! after the type / scope) introduces a change to the API. This means that it breaks pre-existing code.
• chore: A commit that updates something in the repo that does not directly correlate to the code. (For instance updating README.md, changing Github Actions, etc.)
• docs: A commit that updates the docs. Not much else here.

There may be more types but ask RayhanADev.

Scopes?

Scopes represent a specific section to the type. They don't have to be anything specific and don't have to have been used before. They just help a reviewer easily tell where the change occurred in case the description is obscure. Some used scopes have been:

• workflow
• contribution (CONTRIBUTING.md)
• repo (general changes)
• readme (for README.md file)

What about Pull Requests?

That's a very good question. I myself am unsure what to do for PRs, but I assume that they follow the same format. Combine all the commits, and find the most important. (Breaking is more important than feat, and fix is more important than docs.)

Semantic Version

A common practice is to make this package follow SemVer or Semantic Versioning. Read over the specs here. They go in direct correlation with Conventional Commits. You guys will not probably have to worry about this, as I will be the one who packages and releases the versions. It's just nice to know.

Closing

I'm sorry for the word wall. After noticing the commit history was a mess I knew I had to do something, though. Please raise any questions in the comments, and remember to also read over CONTRIBUTING.md. Thanks!

~ BD103 :D

Update

Make the short description lowercase. I forgot to mention that!

Finally adding Continuous Integration! I have designed a Python Package that simulates installing from a poetry.lock file. It's called Ballad. Here's what I did:

• Created standard Github Action
• Added linter with Black, Isort, and Flake8
• It actually works!
• Only runs for the master branch (which can be changed)
• Because it's my project, I can add features that are requested

Add continuous integration with Github Actions. Currently, this is a low priority because of the following:

• This project uses Poetry for dependency management
• Github Actions does not initially support Poetry
• Installing Poetry works, but commands are not registered
  • For instance, even though it installed Isort, the isort command isn't available
  • This makes it very difficult to use all the dependencies necessary for the project

Hey! I was just wondering @BD103, since I know python ~~and have no ideas~~, can I join this proj?

If no, that's fine, I'll just leave a couple pull requests here and there

Thanks!

New contributors typically look to a CONTRIBUTING.md and CODE_OF_CONDUCT.md for how to contribute to a repository. Also be sure to specify a Commit Convention (or lack of one) so that commit history is clean. Lastly, if Python has a code linter and/or formatter you should include the setup for these and configuration files so that all your code remains clean and consistent.

Speaking from experience I ran a repository for 3 months without the above and trying to make changes or consistency was a pain. Adopting these best practices will help you run this module smoothly!

This looks like a cool project, but you seem to be lacking a documentation? I would recomend having it in the README file, and you should make sure it also goes on Pypi to.

Github to Replit sync broken I checked out our team repl for the python module, and tried both pulling and pushing. However, as this does happen, the sync has broke. I already left a message inside the repl, but I'm leaving an issue as well. You might want to import this GitHub repo in Replit.

Just letting you know

To Reproduce Steps to reproduce the behavior:

1. Go to 'Version Control'
2. Click on 'Pull'
3. Click on 'Push' this time
4. See error

Expected behavior It's supposed to pull for you and push for you as it's synced, but it doesn't. It reacts like a null (lol).

Screenshots Check the repl for more.

Desktop (please complete the following information):

• OS: ChromeOS
• Browser: Chrome
• Version: 91.0.4472.81 (i think)

You may want to setup a Kanban board in Projects to track issues and deadlines for your first release of the module. It might help keep things organized when transpiling the NodeJS package to a Python Module.

Previously when fetching the staging domain you could use HTTP requests (i.e. what the requests package uses) however when fetching the standard domain that is no longer the case. You need to use an HTTPS package. I would experiment with urllib, although I'm not sure if it supports https. Worst case scenario if nothing works you can use the native Python HTTPS APIs, make your own package (you only need GET and POST requests) and use that (it's what I did for the NodeJS package).