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.

What's the difference between the REPLAPI.it-Python and the REPLAPI?

Currently, we need to support two classes:

• User
• Post

I have laid down the framework for these, but they do not actually do anything.
Remember, this package should work exactly as ReplAPI-it-NodeJS, ideas for features should be implemented there first, then ported.

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).

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!

I am currently working on Ballad 2.0.0. This issue will stay open until I release this new version.

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)

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.

Hiya, quick question;

Where did the python files go? ;-;

Thanks! :D

Docs

So, I noticed that we don't have any docs, even an MD set up for how to use the module, and it's really bugging me, so, I was wondering if we could get a doc website set up with vercel, or even an MD ready for when it's time to write the docs.

This is just a request, thanks!

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!

Should we upload this to PyPi? Or should we just make it an unofficial module? (for python)

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.

What happened to this package? It hasn’t been worked on for a while. Just askin

Is it possible to make the Ballad Badge a for-the-badge style to match up with the other badges?

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!

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

Heya, could you invite me to this? I haven't got the invite yet ;)