Skip to main content

Package Description, Installation and usage guide.

Use cases : 
To create logfiles and write to multiple log files from the same script.

1. Installation

pip install easymultilogging

2. Usage

CreateLogs is the class inside easymultilogging package that is to be imported.

from easymultilogging import CreateLogs as cl

3. Arguments for CreateLogs class

  • log_dest_dir : Path to the directory where the log file is to be saved.
  • log_dest_dir : Path to the directory where the log file is to be saved.
  • log_file_name : Name of the log file. (The log file can be accessed at : 'log_dest_dir/log_file_name')
  • log_format : Can be defined while intiallizing the class object, however the default argument is '%(asctime)s %(name)-12s%(levelname)s:%(message)s'
  • log_set_level : User defined logging set levels. Default value = 'DEBUG'.

See the section #3.1 for the other common logging levels that can be passed on as an input to the - log_set_level variable.

3.1 - Common Logging Levels

So what are these logging levels? Here are some common ones that you'll see, listed in order from most severe to least severe, and followed up by some that are meta-considerations. When logging from your application, follow these guidelines:

FATAL (log_set_level = 'FATAL')

Fatal represents truly catastrophic situations, as far as your application is concerned. Your application is about to abort to prevent some kind of corruption or serious problem, if possible. This entry in the log should probably result in someone getting a 3 AM phone call.

ERROR (log_set_level = 'ERROR')

An error is a serious issue and represents the failure of something important going on in your application. Unlike FATAL, the application itself isn't going down the tubes. Here you've got something like dropped database connections or the inability to access a file or service. This will require someone's attention probably sooner than later, but the application can limp along.

WARN (log_set_level = 'WARN')

Now we're getting into the grayer area of hypotheticals. You use the WARN log level to indicate that you might have a problem and that you've detected an unusual situation. Maybe you were trying to invoke a service and it failed a couple of times before connecting on an automatic retry. It's unexpected and unusual, but no real harm done, and it's not known whether the issue will persist or recur. Someone should investigate warnings.

INFO (log_set_level = 'INFO')

Finally, we can dial down the stress level. INFO messages correspond to normal application behavior and milestones. You probably won't care too much about these entries during normal operations, but they provide the skeleton of what happened. A service started or stopped. You added a new user to the database. That sort of thing.

DEBUG (log_set_level = 'DEBUG')

With DEBUG, you start to include more granular, diagnostic information. Here, you're probably getting into "noisy" territory and furnishing more information than you'd want in normal production situations. You're providing detailed diagnostic information for fellow developers, sysadmins, etc.

TRACE (log_set_level = 'TRACE')

This is really fine-grained information-finer even than DEBUG. When you're at this level, you're basically looking to capture every detail you possibly can about the application's behavior. This is likely to swamp your resources in production and is seriously diagnostic.

ALL (log_set_level = 'ALL')

This is just what it sounds like. Log absolutely everything, including any custom logging levels that someone has defined.

OFF (log_set_level = 'OFF')

This is also just what it sounds like. Don't log anything at all.

For extra info, please refer "https://stackoverflow.com/questions/2031163/when-to-use-the-different-log-levels"

Sample

#CreateLogs is the class inside easymultilogging package that is to be imported.
from easymultilogging import CreateLogs as cl

#Create an object of the class CreateLogs. 
# Lets go ahead and create objects 'p1,'p2' for our sample script 

p1 = cl(log_dest_dir = 'C:\Opex Projects\McD-Toys-master\Source', log_file_name = 'testpackage_29.txt', log_set_level = 'DEBUG')
p1.logger.debug("-------process : 1")

p2 = cl(log_dest_dir = 'C:/Opex Projects/McD-Toys-master/', log_file_name = 'testpackage_30s.txt')
p2.logger.info("------process : 2")

#p2.logger.info(subprocess.check_output[arg1,arg2]) is a good example of how the object can be used to capture subprocess execution logs as well !

Metadata

Release files for easymultilogging 0.0.6

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for easymultilogging 0.0.6
File Size Uploaded Provenance Actions
easymultilogging-0.0.6.tar.gz 4.1 kB Without provenance Details for easymultilogging-0.0.6.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for easymultilogging 0.0.6
File Interpreter ABI Platform Actions
easymultilogging-0.0.6-py3-none-any.whl Python 3 none any Details for easymultilogging-0.0.6-py3-none-any.whl

Total release size: 9.4 kB

Release files / easymultilogging-0.0.6.tar.gz

Download URL easymultilogging-0.0.6.tar.gz
Size 4.1 kB
Tags Source
SHA-256 checksum
How to use checksums
4aaaded02a38fd7508bd7d7d0c4baeb11473199ea792d0094f7168d4993c068a
BLAKE2b-256 checksum
How to use checksums
a127cdbf694d40492c0b986a7031771c209f32e09145f10b79b31807c637f27d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/2.0.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.4.0 requests-toolbelt/0.9.1 tqdm/4.36.1 CPython/3.7.3

Release files / easymultilogging-0.0.6-py3-none-any.whl

Download URL easymultilogging-0.0.6-py3-none-any.whl
Size 5.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
67591086a553579ac428d027f3b9a39efef6a27bf2d4132f51feba18c546fe09
BLAKE2b-256 checksum
How to use checksums
e7cb26b81465fd728e1cb169061f4e5a1747abb8dceef14f82f4ad39ab95b01c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/2.0.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/41.4.0 requests-toolbelt/0.9.1 tqdm/4.36.1 CPython/3.7.3

Security for easymultilogging 0.0.6

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page