'if not "giveaway rig" in str(ctx.command): AttributeError: 'CheckFailure' object has no attribute 'command'` Can you tell how to fix this? - command

This is my code:
#bot.event
async def on_command_error(error, ctx):
if not "giveaway rig" in str(ctx.command):
if isinstance(error, commands.CommandNotFound):
pass
elif isinstance(error, commands.MissingRequiredArgument):
await send_cmd_help(ctx)
elif isinstance(error, commands.BadArgument):
await send_cmd_help(ctx)
else:
await ctx.bot.send_message(ctx.message.channel, defaultGiveawayErrorMessage)
And when it runs, this error shows:
if not "giveaway rig" in str(ctx.command):
AttributeError: 'CheckFailure' object has no attribute 'command'
How can I fix this?

The issue at hand:
You've got your event's parameters the wrong way round.
Swap them around like so:
async def on_command_error(ctx, error):
Discord.py version:
And from the looks of things, you seem to be using some async code:
await ctx.bot.send_message(ctx.message.channel, defaultGiveawayErrorMessage)
which, in rewrite (v1.x), can be written as:
await ctx.send(defaultGiveawayErrorMessage)
The rewrite and async versions of d.py are not compatible, and you will need to update your version of d.py.
You can do this by running:
pip install -U discord.py
and you'll know whether you have the rewrite version judging by if you see this in your output:
Requirement already up-to-date: discord.py in c:\PATH\TO\python\python35\lib\site-packages (1.X.X)
(Note the version number at the end)
Some issues that may arise:
You've got it installed successfully, but running your script errors when using rewrite's documentation.
Cause: This is because you may be trying to run the script on a version of python that discord.py wasn't installed on.
Fixes:
If this was done in a virtual environment, it should be an easy enough fix - just open up the venv's terminal and make sure you run the command there (not in your cmd prompt!).
If you're not using a venv, it'd be your best bet to just make sure you have one version of Python installed.
Whenever you run the command pip install -U discord.py, you're only getting v0.16.x installed.
Cause: You're installing the package on an outdated version of Python.
Fixes:
discord.py, as of this answer, only supports Python versions 3.5.3 and above.
This means that you need to upgrade your version of Python.
If you're still encountering this issue and you're sure you've got a version of 3.5.3 or above, check the current versions of Python that discord.py supports. A nice and simple fix for this is to make sure you only have one version of Python installed again.
And with that being said, I highly recommend using the rewrite docs, and if you want to follow any tutorials, make sure they're up-to-date (include rewrite as a keyword in your searches).
The rewrite version is much, much nicer than async, and at first it may be a bit difficult to get to grips with what's changed, which is what this page is for. It'll help build the foundations for your migration to the newer d.py version.
References:
Major model changes - Moving from async to rewrite, I highly recommend reading through this, as it could fix any issues that you run into when you get started.
OS-specific installations - For if you're still running into issues during installation.
on_command_error()
commands.Context - You will, depending on what your bot does, be using context instances a LOT of the time. Get familiar with what attributes and methods you can access - it'll save you a lot of headaches in the future.

Related

omp_set_nested routine deprecated, please use omp_set_max_active_levels instead

I started getting the following warning repeatedly when running my PyTorch Lightning deep learning scripts, at execution start and then all through the training:
"OMP: Info #276: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead."
I get them when executing the main.py script; my scripts are publicly available here.
Symptoms:
I don't think it has anything to do with PyTorch Lightning, maybe even PyTorch.
It appeared overnight, so I don't know what could cause it.
It runs fine without those warnings on my PC.
I get the warnings when I run from my M1 Mac.
I use VSCode for both, each up to date.
I use separate miniconda environments.
Thanks for taking the time to reply!
I managed to sort myself out in the end.
I spotted the numba package in my miniconda env, which is a Python compiler and that seemed to be the root of the problem.
It was version 0.55.2 but the last version to date is 0.56.0. Trying to upgrade it via conda or pip didn't work for some reason (the 0.55.2 version couldn't be replaced).
I recreated my env step by step, and noticed this package comes with torch-audiomentations, a package for audio data augmentation for deep learning, under torch, that I use.
Re-installing it had numba version 0.56.0 installed properly, and the warnings disappeared.
That routine is deprecated, meaning that newer standards want you to use another routine. If you can not edit the code, just ignore. For now it's only an info message. You got that message when you switched to a newer OS / compiler version / OpenMP version.

What causes Python Pytube to send me a HTTP ERROR 410 each time

I want to make a small python project and I am quite new with it. So I thought a youtube-downloader is a funny project to go by. So I looked at the documents about how to and installed everything accordingly. Now I am facing a strange 410 error. I searched on this platform the issue and some were resolved due an answer and some stayed open without closure.
The answers I found is if I(You) have the right pytube version installed. Besides that answer there was also a git repository available which I tried and it didn't work. That one is
pip install git+https://github.com/Zeecka/pytube#fix_1060
With this I still get the same error.
Anybody any clue what I do wrong? Every other example I see and want to recreate to make sure it works just doesn't for me. I feel like I misplaced a package somewhere and that's how it's poorly/unreadable.
Python version: Python 3.10.2,
pip 21.2.4 from C:\Python\Python310\lib\site-packages\pip (python 3.10)

readthedocs and setuptools scm version wrong

I have a package I just updated to use setuptools_scm and found the version number is wrong in readthedocs.
http://sshuttle.readthedocs.org/en/v0.77/ shows:
Version: 0.78.dev0+ng083293e.d20160304
however as version 083293e has the 0.77 tag, the version string should be just 0.77
It looks like readthedocs might be making changes to my source code before building.
I have looked at the readthedocs build logs, and it seems to have the correct version at one stage (0.77), however this is before it builds the documentation.
Processing dependencies for sshuttle==0.77
Finished processing dependencies for sshuttle==0.77
The build logs don't mention the version while building the documentation.
Is it possible to solve this?
Thanks
I see that you're building this project.
Clearly, something is mutating the repository state before the version is determined. You can replicate similar behavior by mutating one of the files prior to building the docs yourself:
(sshuttle) $ python setup.py --version
0.77
(sshuttle) $ cat >> setup.py
# a comment
(sshuttle) $ python setup.py --version
0.78.dev0+ng083293e.d20160403
In the read the docs docs, there's a description of the process.
There, you can see the steps RTD does, namely, (a) run setup.py install then (b) install requirements in requirements.txt.
I've confirmed that neither of those steps should be mutating the repo state.
What it doesn't explain, however, is where that 'version' comes from, or what update_imported_docs does. I suspect the issue lies in something subtle that read the docs is doing that modifies the repo.
Here's one place where the conf.py file gets modified.
Perhaps adding docs/conf.py to your .gitignore will allow those changes to be ignored and thus not dirty your working state when calculating the project version.
https://github.com/pypa/setuptools_scm/issues/84 has been updated to record this
we will be working with the sphinx team to provide a automated/painless version of this process
The documentation for setuptools_scm now has instructions on how to use with readthedocs:
It is discouraged to use setuptools_scm from sphinx itself, instead
use pkg_resources after editable/real installation:
from pkg_resources import get_distribution
release = get_distribution('myproject').version
# for example take major/minor
version = '.'.join(release.split('.')[:2])
The underlying reason is, that
services like readthedocs sometimes change the workingdirectory for
good reasons and using the installed metadata prevents using needless
volatile data there.
This avoids the need to use kluges as per the other answer.

Problems with postgres and Unicorn server

When I try running Unicorn after setting up postgres (works perfectly with Trinidad and Thin) I get the following error.
dyld: lazy symbol binding failed:
Symbol not found: _rb_thread_select
Referenced from:/Users/pls/.rvm/gems/ruby-2.2.0#coinino/extensions/x86_64-darwin-13/2.2.0/do_postgres-0.10.14/do_postgres/do_postgres.bundle
Expected in: flat namespace
Datamapper connects to the database normally inside a model.rb which then is required in app.rb.
What is wrong and how do I fix it?
Edit: Looks like this is a bug in Ruby 2.2.0.
A call used by old versions of the pg gem has been removed in Ruby 2.2. More recent versions of the gem no longer use this call; I know the latest version (0.18.1) doesn't, but I don't know when that change was made. You can update the pg gem by running the following command:
bundle update pg
As long as you're doing this, you may want to run just a plain bundle update to update all of your project's gems to the most recent versions—who knows what else might be incompatible with Ruby 2.2?
As always when updating dependencies, test that the update doesn't introduce any new bugs before you deploy the new version to production. I doubt pg will cause any problems, but other gems might.
It looks like this is a bug in Ruby 2.2.0. Going to Ruby 2.1.5 gets things going without trouble.

How to deactivate django plugin for some tests?

I'm running some tests for Django, and some other tests for the website using Selenium.
My choice of Testing framework is amazing Pytest.
for testing Django I've currently installed pytest-django plugin and tests for Django run as expected, however now I'm back to my previous tests that don't need Django plugin.
I start tests and the Django plugin is picked up automatically.
I've checked the documentation and found the article where it is explained how to disable\deactivate plugins, however when I run this command:
py.test -p no:django
I get an error that my "DJANGO_SETTINGS_MODULE" is not on sys.path.
Also
commands like:
py.test --traceconfig
or
py.test --version
throw me the same error.
Looks like Django plugin is getting to deep? Why is it called when I'm just checking the version or the 'installed plugins'?
QUESTION: Is there any way to temporary deactivate this plugin without uninstalling it?
This should work. When i install pytest-2.3.4 and run py.test -p no:django --version i don't get the DJANGO_SETTINGS issues. I get it when i leave away the -p no:django disabling.
If it doesn't work, please link to a full trace on a pastebin.
IIRC this is because of a combination of things:
On startup py.test looks for the setuptool entrypoint "pytest11"
Entrypoints get imported before they get activated or deactivated
pytest-django (as released, currently 1.4) does a load of Django imports upfront
A lot of Django needs the settings module configured even at import time
Unfortunately this is unavoidable in the released version of pytest-django. And the answer originally was: no, run the pytest-django and other tests in different virtualenvs.
However it is also the reason we started work on a version of the plugin which avoids these problems. What I consider the best version right now is the pytest23 branch at https://github.com/flub/pytest_django This version is pretty feature complete, certainly compared to the released version, it just needs a little more polishing mainly on the tests and documentation.
I believe/hope that within the next few weeks this branch will be merged and released, I just need to get Andreas to have a look through and agree. I consider it certainly stable enough to start using.