So the previous answer to this question doesn't seem to work for me. But I think this problem has something to do with my package references or my setup.cfg file.
I have two tests (just to start with to try and get this working) the results are:
================================ test session starts ==================================================================================================================================================================
platform win32 -- Python 3.7.10, pytest-6.1.1, py-1.9.0, pluggy-0.13.1 -- C:\Users\heasm\Anaconda3\envs\UofS\python.exe
cachedir: .pytest_cache
rootdir: C:\USask Python\geo_calcs, configfile: setup.cfg
collected 0 items
================================= warnings summary ====================================================================================================================================================================
..\..\Users\heasm\Anaconda3\envs\UofS\lib\site-packages\_pytest\config\__init__.py:1230
C:\Users\heasm\Anaconda3\envs\UofS\lib\site-packages\_pytest\config\__init__.py:1230: PytestConfigWarning: Unknown config option: collect_ignore
self._warn_or_fail_if_strict("Unknown config option: {}\n".format(key))
-- Docs: https://docs.pytest.org/en/stable/warnings.html
================================ 1 warning in 0.61s ===================================================================================================================================================================
Now my setup.cfg file is:
current_version = 0.1.0
commit = True
tag = True
[bumpversion:file:setup.py]
search = version='{current_version}'
replace = version='{new_version}'
[bumpversion:file:geo_calcs/__init__.py]
search = __version__ = '{current_version}'
replace = __version__ = '{new_version}'
[bdist_wheel]
universal = 1
[flake8]
exclude = docs
[tool:pytest]
collect_ignore = ['setup.py']
My test cases all seem to be named correctly. Here is an example:
from geo_calcs.calculations.geochem import *
#pytest.fixture
def test_get_atomic_weight():
assert get_atomic_weight(["Si","O","O"]) == 60.0843
Finally my directory structure is:
+---geo_calcs
| | .editorconfig
| | .gitignore
| | .travis.yml
| | AUTHORS.rst
| | CONTRIBUTING.rst
| | HISTORY.rst
| | LICENSE
| | Makefile
| | MANIFEST.in
| | README.rst
| | requirements_dev.txt
| | setup.cfg
| | setup.py
| | tox.ini
| +---docs
| | authors.rst
| | conf.py
| | contributing.rst
| | history.rst
| | index.rst
| | installation.rst
| | make.bat
| | Makefile
| | readme.rst
| | usage.rst
| |
| +---geo_calcs
| | | utils.py
| | | __init__.py
| | |
| | +---calculations
| | | | geochem.py
| | | | geochron.py
| | | | __init__.py
| | | |
| | +---visualizations
| | | __init__.py
| |
| \---tests
| | test_utils.py
| | __init__.py
| |
| +---calculations
| | | test_geochem.py
| | | test_geochron.py
| | | __init__.py
| |
| +---visualizations
| | | __init__.py
Does anyone have any insight?
Remove the #pytest.fixture decorator from above the test. Tests shouldn't have that, they're discovered by naming convention.
Pytest uses glob-style name patterns to collect tests, and the discovery can be customized by the options python_files, python_classes, and python_functions in the configuration file.
The default patterns are:
[pytest]
python_files=test_*.py
python_classes=Test*
python_functions=test_*
Related
Is it possible to have more than one static folder in flask app? I have some .css and .js files which I am using only for certain blueprint and would like to have the files in same directory as blueprint.
My app has structure like this:
app
|
| blueprints
| |
| | blueprint_1
| | |
| | | views.py
| | | __init__.py
| |
| | blueprint_2
| | |
| | | views.py
| | | __init__.py
|
| static
| |
| | css, js, etc.
And I would like to have structure like this:
app
|
| blueprints
| |
| | blueprint_1
| | |
| | | views.py
| | | __init__.py
| | | static
| | | |
| | | | certain css, js, etc
| |
| | blueprint_2
| | |
| | | views.py
| | | __init__.py
| | | static
| | | |
| | | | certain css, js, etc
|
| static
| |
| | css, js, etc.
And similar thing with templates.
While I am using .js file in template I access it with:
{{url_for('static'), filename='jsfile'}}
Okay, I figured it out.
According to docs, if the blueprint does not have a url_prefix, it is not possible to access the blueprint’s static folder.
The solution then is:
Add url_prefix to Blueprint:
some_blueprint = Blueprint('something', __name__, static_folder='static', url_prefix='/something')
and in the template we refer to our static folder as it follows:
{{url_for('something.static', filename=...)}}
It seems kinda weird to me, that url_prefix is necessary for it to work, but whatever.
Hel lo I need to import a package called ete3:
from ete3 import EvolTree
Vut here is my question :
I have 2 localisations for this package :
~/path1/path2/ete3
~/path1/path3/ete3
and I changed manually some commande line in this one : ~/path1/path3/ete3
But when I call ete3 in python3.7, it calles the one here : ~/path1/path2/ete3 but I would like to import the other one present here ~/path1/path3/ete3
Does someone have an idea how to do it ?
Thank you for your help
Add empty file __init__.py in your folders so you can import them as
from path1.path3.ete3 import EvolTree
Like below
Project
|
+-- path1
| |
| +-- file __init__.py
| +-- path2
| | |
| | +-- __init__.py
| | +-- ete3
| | | |
| | | +-- __init__.py
| +-- path3
| | |
| | +-- __init__.py
| | +-- ete3
| | | |
| | | +-- __init__.py
I am trying to import a function from the directory in the same project. how can i do that ?
.|____project/
| |_____src/
| | |____myproject/
| | | | __init__.py
| | | |____funtion.py
| |_____test/
| | |___ testmyproject.py
| | |____data/
| | |___testdata
How can i import the the file function.py or the functions in the function.py file in my test/testmyproject.py to test the fucntions? i am not able to import the module from function.py
I'm running an SConscript which is called by a SConstruct which does nothing but set the environment and Export('env'). The SConscript is supposed to iterate over files with filenames like mod_abc.c and for each of these files - First create an xml dir, generate a structdoc, create a file mod_abc_post.c and then an object file and a '.so' file. After that it should remove the xml file and restart the process for the next mod_*.c file.
Heres the script:
import os
Import('env')
my_libs = 'jansson'
postc_files = Glob('mod_*_post.c')
all_mods = Glob('mod_*.c')
mods = set(all_mods) - set(postc_files)
mods = list(mods)
env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=1
xml_cmd_str = '(cat ../Doxyfile.configxml; echo "INPUT=%s";) | doxygen - > xml%s'
structdoc_cmd_str = 'python ../prep_structdoc.py xml mod_config mod_mtx update_mtx serialize_mtx "mod_evt_" > %s'
preprocess_cmd_str = 'python ../preprocess_mod.py xml %s %s > %s'
for mod in mods:
#create doxy file
xml_dir = env.Command('xml%s' % mod.name, mod, xml_cmd_str % (mod.name, mod.name))
mod_name = mod.name[:-2]
struct_doc = '%s.structdoc' % mod_name
#using Command instead of os.popen as clean can take care of structdoc
sdoc = env.Command(struct_doc, xml_dir, structdoc_cmd_str % struct_doc)
processed_file= '%s_post.c' % mod_name
pfile = env.Command(processed_file, sdoc, preprocess_cmd_str % (mod_name, struct_doc, processed_file))
obj_file = env.Object(target='%s.o' % mod_name, source=pfile)
shared_target = '%s.so' % mod_name
env.SharedLibrary(target=shared_target, source=obj_file, LIBS=my_libs)
py_wrapper = env.Command('%s.py' % mod_name, pfile, 'ctypesgen.py %s %s -o %s' % (processed_file, mod.name, '%s.py' % mod_name))
# remove xml once done
remove_xml = env.Command('dummy%s' %mod.name, py_wrapper, 'rm -rf xml')
Ive taken care that xml_dir target gets a particular name as that xml command should be run only for that mod_name. The problem is that the dependency tree is not as expected.
I expect a tree like this for each of the files
-remove xml
--create py_wrapper
---create so file
----create o file
-----create _post.c file
------create .structdoc file
-------create xml directory
But what I get by doing scons --tree=ALL is for example just one of them mod_serialize_example.c is:
The dont come in order, there are things in the middle as well which are for other mod_*.c files.
[Some other things before this]
+-dummymod_serialize_example.c
| +-mod_serialize_example.py
| | +-mod_serialize_example_post.c
| | | +-mod_serialize_example.structdoc
| | | | +-xmlmod_serialize_example.c
| | | | | +-mod_serialize_example.c
| | | | +-/usr/bin/python
| | | +-/usr/bin/python
| | +-/usr/local/bin/ctypesgen.py
| +-/bin/rm
[Some other things after this]
+-libmod_serialize_example.so
| +-mod_serialize_example.o
| | +-mod_serialize_example_post.c
| | | +-mod_serialize_example.structdoc
| | | | +-xmlmod_serialize_example.c
| | | | | +-mod_serialize_example.c
| | | | +-/usr/bin/python
| | | +-/usr/bin/python
| | +-mod_serialize_example.c
| | +-/path/to/header files included
| | +-/usr/bin/gcc
| +-/usr/bin/gcc
+-mod_addition.c [ Some other module ]
+-mod_serialize_example.c
+-mod_serialize_example.o
| +-mod_serialize_example_post.c
| | +-mod_serialize_example.structdoc
| | | +-xmlmod_serialize_example.c
| | | | +-mod_serialize_example.c
| | | +-/usr/bin/python
| | +-/usr/bin/python
| +-mod_serialize_example.c
| +-/path/to/header files included...
| +-/usr/bin/gcc
+-mod_serialize_example.py
| +-mod_serialize_example_post.c
| | +-mod_serialize_example.structdoc
| | | +-xmlmod_serialize_example.c
| | | | +-mod_serialize_example.c
| | | +-/usr/bin/python
| | +-/usr/bin/python
| +-/usr/local/bin/ctypesgen.py
+-mod_serialize_example.structdoc
| +-xmlmod_serialize_example.c
| | +-mod_serialize_example.c
| +-/usr/bin/python
+-mod_serialize_example_post.c
| +-mod_serialize_example.structdoc
| | +-xmlmod_serialize_example.c
| | | +-mod_serialize_example.c
| | +-/usr/bin/python
| +-/usr/bin/python
+-pfile
+-xml
[some other stuff]
+-xmlmod_serialize_example.c
+-mod_serialize_example.c
What i would expect for mod_serialize_example.c is
+-rm xml
|+-libmod_serialize_example.so
| +-mod_serialize_example.o
| | +-mod_serialize_example_post.c
| | | +-mod_serialize_example.structdoc
| | | | +-xmlmod_serialize_example.c
| | | | | +-mod_serialize_example.c
| | | | +-/usr/bin/python
| | | +-/usr/bin/python
| | +-mod_serialize_example.c
| | +-/path/to/header files included
| | +-/usr/bin/gcc
| +-/usr/bin/gcc
However, I see this and a lot more than required. (also the above one was just manually done to give an idea of the process, pardon the indentation with the + and | )
Shouldn't they all bunch up together ? (As shown in the expected tree, and repeat like a loop for the different filenames).
Also, Im just getting started with scons and any help in making this design cleaner would be helpful.
1. I would like to know how to get the expected tree
2. How can I make this script take a module name and run the for loop code only on that.
example: scons mod_abc.c should create the .so file only for that.
As of now, this doesnt produce anything if i do that.
Why would you expect a tree like that? There's no (explicit or implicit) dependency of anything else on your shared library for instance. So it will go as one of the targets at the top of the graph.
Consider the following file\directory structure:
project\
| django_project\
| | __init__.py
| | django_app1\
| | | __init__.py
| | | utils\
| | | | __init__.py
| | | | bar1.py
| | | | ...
| | | ...
| | django_app2\
| | | __init__.py
| | | bar2.py
| | | ...
| | ...
| scripts\
| | __init__.py
| | foo.py
| | ...
How should I use sys.path.append in foo.py so that I could use bar1.py and bar2.py?
How would the import look like?
Using relative paths would be much more desirable for portability reasons.
At the top of your foo.py script add the following:
import os, sys
PROJECT_ROOT = os.path.join(os.path.realpath(os.path.dirname(__file__)), os.pardir)
sys.path.append(PROJECT_ROOT)
# Now you can import from the django_project package
from django_project.django_app1.utils import bar1
from django_project.django_app2 import bar2
import sys
sys.path.append('/absolute/whatever/project/django_project/django_app1')
sys.path.append('/absolute/whatever/project/django_project/django_app2')
Though you need to evaluate whether you want to have both in your path -- in case there are competing module names in both. It might make sense to only have up to django_project in your path, and call django_app1/bar1.py when you need it and import django_app2.bar2.whatever when you need it.