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.
Related
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.
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.
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.
It's Typesafe Activator 1.2.10 on Windows 7, Scala 2.11.4, sbt 0.13.7. All packages installed using .msi.
When I run activator ui I get error:
Error: Could not find or load main class ui
and nothing happens then.
It appears that you're facing permission-related problems.
I can't give you the exact steps to sort it out (as I'm on Mac OS), but you should be able to work it around by running cmd as Administrator and then executing activator ui again.
There's also the version 1.2.12 so you may have more success with it. You don't need separate installations of Scala and sbt, either, as activator is going to take care of them (that's one of the many reasons to use the tool after all).
I have installed Net-SMTP-SSL (/usr/bin/perl install-module.pl Net::SMTP::SSL) since I'd like to configure Bugzilla email with Gmail. I did't got any error. However, when I run './checksetup.pl --check-modules', I still get the result:
Checking for Net-SMTP-SSL (v1.01) not found
I also try to re-install it and I still get the same output. Here is my system information:
Ubuntu 12.04
Bugzilla 4.4.6
After having the same problem with Bugzilla recently, I ran across this rejected bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=897355
It mentions that there are some dependencies that Bugzilla isn't installing, but doesn't say which ones. So I just ran cpan and issued the upgrade command from the cpan console to upgrade all packages. This went though and installed a few dependencies from various packages that it said were missing. I didn't see which ones were related to the SMTP SSL package since it was installing stuff several levels deep in dependencies, but after running that and then running checksetup.pl in Bugzilla, the problem seemed to be fixed. Warning: It did take quite a while to upgrade all packages, though.
That fixes the issue with Bugzilla not detecting properly, but unfortunately it seems there's a bug in Net::SMTP::SSL conflicting with one of it's own dependencies. You'll get an error something like "Not a GLOB reference" if you try to run the package directly. You can see it by running this after updating all of the packages:
perl -MNet::SMTP::SSL -wE 'say $Net::SMTP::SSL::VERSION'
If you get a version number returned then it's working, but I get an error and have seen other posts about it, too. I haven't been able to fix this problem yet, but there's probably some combination of the SSL package and various versions of it's dependencies that actually works, just not the latest of each. Otherwise, I would think there would be a known issue in Bugzilla release notes as they would have run across it during testing.
I haven't had time to do it and haven't seen that anyone else has either including the package maintainer, but I suppose you could find all of the dependencies for Net::SMTP:SSL and then one by one update the packages using something like:
cpan upgrade Net::SMTP::SSL
Then replace Net::SMTP::SSL with each of it's dependencies one at a time and test using the perl command above. When it breaks, you'll know which package is conflicting. You can then roll that package back to an earlier version and update all other dependencies and hopefully it will fix the issue. It's definitely possible that no combination will work, though, and if that's the case, I'll be a little disappointed in Bugzilla's testing process.
You can find dependencies using various methods, but CPAN has one. Here's a link to an article about how to create a perl script to use it: https://metacpan.org/pod/CPAN::FindDependencies
Anyway, this may not solve your problem, but I hope it helps in tracking down the issue, and know that you are not alone. If you do find out anything, please post it here. I will do the same if I have more time to work on it later.