Can anyone clarify how pytest hooks executes and what it does in each step?
Mainly, could you please tell me why pytest_plugin_registered is repeated under pytest_sessionstart?. I checked pytestdebug.log and it repeats the same plugins' registration.
root
└── pytest_cmdline_main
├── pytest_plugin_registered
├── pytest_configure
│ └── pytest_plugin_registered <-------- registers all _pytest plugins, conftest, setup tools plugins
├── pytest_sessionstart
│ ├── pytest_plugin_registered <-------- again registers all same above _pytest plugins, conftest, setup tools plugins
│ └── pytest_report_header
https://github.com/pytest-dev/pytest/issues/3261#issuecomment-755461808
Related
I am trying to create a debian package for a postgreSQL extension Apache-age release 1.1.1 and created the directory structure using dh_make command.
The directory structure is as follows:
age-1.1.1 (project root)
├── debian
│ ├── changelog
│ ├── compat
│ ├── control
│ ├── docs
│ ├── examples
│ ├── links
│ ├── manpages
│ ├── menu
│ ├── postinst
│ ├── postrm
│ ├── preinst
│ ├── prerm
│ ├── rules
│ ├── source
│ └── watch
├── src
└── Makefile
The dpkg-buildpackage -b when run from project-root folder it looks for debian folder, then reads the rule file, then reads the Makefile located in the project root to build the package.
I want to change the directory structure to the following:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ └──
├── src
├── LICENSE
├── README.md
├── Makefile
└── ...
I want to change the directory structure so that the dpkg-buildpackage -b command can be run from the packaging folder and it should build the package.
Inside your Makefile
Modify the install paths accordingly. It should point to your packaging/debian/* where * is the filename.
This way the Makefile can point to the correct file path target inside the new folder structure.
I'm not sure if this is the best way to do this but it's working for me:
Here are the steps:
First run the dh_make_pgxs command from the project root directory.
Create a packaging directory in the project root and move the debian directory created in step 1 to this directory along with the Makefile, age.control and the age--1.1.1.sql.
Your file structure should look like this:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ ├── age--1.1.1.sql
│ ├── age.control
│ ├── Makefile
│ └── ...
├── src
├── LICENSE
├── README.md
└── ...
Change the file paths in the Makefile like:
src/backend/age.o should be ../src/backend/age.o.
./tools/ should be ./../tools/.
and so on.
Now you can simply run the dpkg-buildpackage -b command from the packaging directory to build the debian package.
Note: In step 1 we are running dh_make_pgxs in the project root first, this is to make sure that the project name in the control files and the version in the changelog file are correct. In this case the name/source in control, control.in & changelog files should be apache-age and the version number in changelog file should be 1.1.1-1.
Alternatively, you can run the command from the packaging directory and manually change the name and version in the control and changelog files.
I am working in a somewhat substantial application, and there is some common logic that I've put in an utils.py (you can tell where this is going).
I am not sure where I should put utils.py, or if I should have more than one copy of it, or if I should install it as a module itself.
Consider this simplified application layout from realpython.com
helloworld/
│
├── helloworld/
│ ├── __init__.py
│ ├── runner.py
│ ├── hello/
│ │ ├── __init__.py
│ │ ├── hello.py
│ │ └── helpers.py
│ │
│ └── world/
│ ├── __init__.py
│ ├── helpers.py
│ └── world.py
│
└── README.md
You have the two main files hello.py and world.py, and there is some hello.py specific helper functions in the adjacent helpers.py.
However, what if there is a substantial amount of logic that is common to both helpers.py; say a sqlalchemy connection or some dataclasses that are endemic across the application.
To make the conversation concrete, suppose I have a dataclass User that is needed pretty much everywhere. Where should I put the file that defines User so that it is available in all the other .py files?
On the one hand I understand the idea behind a directory tree (it's not a tree if the leafs all import utils.py). But what's the alternative? To copy that logic everywhere?
I would like to use the nx:affected:build command to only build the apps that are affected by the last commit in an nx/xplat workspace.
Let's say I have 2 angular web apps web-app1 and web-app2.
.
├── apps
│ ├── web-app1
│ └── web-app2
├── libs
│ ├── core
│ └── features
│ └── app1
│ └── app2
└── xplat
└── web
└── features
└── app1
└── app2
When I make a change to /xplat/web/app1 I would expect the nx:affected:apps command to only show the web-app1 app. However nx thinks that the commit affects both apps. (**web-app2 ** does not import the app1 feature.)
nx affected:apps --base=head~1 --head=head
I've created a sample repo to demostrate: https://github.com/barryajones/workspace-affected-test
Is there any de facto standard for the filesystem output layout of compiled CoffeeScript output?
Or: where should the .js and .map files end up?
I currently have a file watcher1 compiling the output to ./grounds/[whatever] to keep the source folder clean, so I end up with something like:
index.html
/js
├──foo.js
├──bar.js
/coffee
├──a.coffee
├──b.coffee
├──/grounds
│ ├──a.js
│ ├──a.map
│ ├──b.js
│ ├──b.map
├──/some-module
│ ├──c.coffee
│ ├──/grounds
│ │ ├──c.js
│ │ ├──c.map
Just curious if I missed the boat on some existing standard for the output file layout, or if folks generally just let them all be siblings in the same folder and are happy with that.
1: Pycharm
I don't think they is any standard, but for development, I use the same structure for the JS than for the coffee:
eg:
coffee
├── AdvancedStatsModule.coffee
├── board
│ ├── Board.coffee
│ ├── Card.coffee
├── controllers
│ ├── directives.coffee
│ ├── factory.coffee
│ ├── filters.coffee
│ ├── ListController.coffee
public/js
├── AdvancedStatsModule.js
├── board
│ ├── Board.js
│ ├── Card.js
├── controllers
│ ├── directives.js
│ ├── factory.js
│ ├── filters.js
│ ├── ListController.js
Advantages for this:
JS and coffee are not mixed
The coffee directory is not public
For production, I usually concat and minify my files anyway.
Update:
I use gulp for that. My Gulpfile:
var watch= require('gulp-watch');
var coffee= require('gulp-coffee');
gulp.src(paths.coffee)
.pipe(watch(function(files) {
return files.pipe(coffee())
.pipe(gulp.dest(paths.js));
}));
I want to create my own Perl module, but the problem is that it contain multiple .pm files. The structure is:
lib
├── A_Z.pm
└── T_test
├── A.pm
├── B.pm
├── C.pm
├── D.pm
└── E.pm
I used h2xs -XA -n T_test::A T_test::B T_test::C T_test::D T_test::E. It compiled only A.pm; the other B.pm, C.pm, D.pm, E.pm are not considered. Is there any solution to execute all the .pm file at the same time?
Use Module::Starter::PBP instead.
$ module-starter --builder=Module::Build --module=A_Z,T_test::{A,B,C,D,E}
Added to MANIFEST: Build.PL
Added to MANIFEST: Changes
Added to MANIFEST: lib/A_Z.pm
Added to MANIFEST: lib/T_test/A.pm
Added to MANIFEST: lib/T_test/B.pm
Added to MANIFEST: lib/T_test/C.pm
Added to MANIFEST: lib/T_test/D.pm
Added to MANIFEST: lib/T_test/E.pm
Added to MANIFEST: MANIFEST
Added to MANIFEST: README
Added to MANIFEST: t/00.load.t
Created starter directories and files
$ tree A_Z
A_Z
├── Build.PL
├── Changes
├── lib
│ ├── A_Z.pm
│ └── T_test
│ ├── A.pm
│ ├── B.pm
│ ├── C.pm
│ ├── D.pm
│ └── E.pm
├── MANIFEST
├── README
└── t
└── 00.load.t
3 directories, 11 files
You don't have to do anything special. Just makes sure all the files are listed in MANIFEST as usual. Both ExtUtils::MakeMaker and Module::Build consider all .pm to be modules to install.