semvec/pypi-packages huggingface dataset:
link-sweep 0.1.1
A tool for checking and cleaning dead links in Markdown files for SSGs
License: MIT
Requires Python: >=3.8
Keywords: ci-cd, hugo, jekyll, link-checker, links, markdown, static-site-generator, zola

# Link Sweep

Link Sweep is a tool for checking and cleaning dead links specifically within Markdown files for use with static site generators like Zola, Hugo, and Jekyll. Dead links have a negative impact on SEO, security and user experience.
This tool was inspired by [DeadFinder](https://github.com/hahwul/deadfinder) and designed to be more lightweight, tailored to my specific needs.

This tool is vastly more limited in scope, being designed specifically for recursively targeting markdown files within a given directory. For broader use cases, I recommend [DeadFinder](https://github.com/hahwul/deadfinder)

## Installation

### From PyPI (Recommended)

```bash
pip install link-sweep
```

### From Source

```bash
git clone https://github.com/yourusername/link-sweep.git
cd link-sweep
pip install -e .
```

## Usage

```bash
# Check links in your content directory
link-sweep check-links content/

# Check with verbose output
link-sweep check-links --verbose content/

# Check and automatically remove dead links (no back-up)
link-sweep check-links --remove-dead content/
```
When using `--remove-dead`, dead links like `[Example](https://dead-link.com)` become just `Example`.

## GitHub Actions Integration

This script was designed with the intention of running as part of GitHub Actions, however, it can be run manually. A generic workflow might look something like this:
```yaml
name: Weekly Link Cleanup

on:
  schedule:
    - cron: '0 6 * * 1'  # Monday 6 AM

jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    
    - name: Fix dead links
      run: link-sweep check-links --remove-dead content/
    
    - name: Create PR if changes
      uses: peter-evans/create-pull-request@v5
      with:
        commit-message: "fix: automated dead link cleanup"
        title: "🔧 Weekly dead link cleanup"
```
The above runs weekly to create a pull request if there are any changes captured within the runner's local files.

## License
MIT License - see LICENSE file for details.

## Changelog

### v0.1.1
- Basic link checking functionality
- Dead link removal option
- CLI interface with Click
- Concurrency for improved perforamance
- Link timeouts
broken-down-models 0.5.0
A set of utlities for breaking a large Django model down to separate components
License: MIT
Requires Python: <4.0,>=3.9
Keywords: Django, models, database, optimization, refactoring

.. image:: https://github.com/matific/broken-down-models/actions/workflows/tests.yml/badge.svg
   :alt: Test status


Break a large model down, transparently
---------------------------------------

In a project that goes on for several years, models tend to grow and
accumulate fields. If you aren't very disciplined about this, you wake up
one day, and find that one of your central tables, one with millions of
rows, has 43 columns, including some TextFields. Most of them are not
required most of the time, but the default (and common) use is to fetch all
of them; also, since this table is queried a lot, the mere fact that it has
so many columns makes some of the access slower.

When you realize that, you want to break it into components, such that
only a few, most-important columns will participate in the large searches,
while further details will be searched and fetched only when needed.

But that is a scary proposition -- it might involve subtle code changes,
break not just field access but also ORM queries... and this is a central
model. The change imagined is open-heart surgery on a large project.
Maybe, if we look the other way, it won't bother us too much...

**broken-down-models** is here to help you. This is a library which can
help you refactor your large model into a set of smaller ones, each with
its own database table, while most of your project code remains unchanged.

How?
----

Django already includes a mechanism where fields for one model are stored
in more than one table: Multi Table Inheritance (also known as MTI).
That's what happens when we do "normal" inheritance of models, without
specifying anything special in the Meta of either of the models.

Python also supports Multiple Inheritance -- one class can have many parent
classes. And this also works with Django's MTI -- we can have multiple MTI.

Usually, when we think of a "core" set of attributes with different extensions,
and we decide to implement it with MTI, we put this core set in a parent
model, and make the extensions subclass it. But in the situation where we
try to break down an existing model, this would mean that code which currently
uses the large model will have to change, to recognize the new parts.

**broken-down-models** puts this idea on its head: The extensions become
parent models, and the core set is defined in a model which inherits them all.
This way, all the fields are still fields of of the model we started with,
for all purposes -- including not just attribute access, but also ORM queries.
For this to really work well, though, some further modifications are required;
this is why the library exists, and it is explained in its `documentation`_.

.. _documentation: https://broken-down-models.readthedocs.io/en/latest/
chemged 0.1.1
Package calculating the approximate graph edit distance between chemicals
License: MIT
Requires Python: <4.0,>=3.11

# ChemGED

ChemGED is a Python package for enabling the appoximate graph edit distance (GED) computation between
chemicals. Normally, GED is a NP-hard problem, but ChemGED uses heuristics to approximate the GED in
a reasonable time.

## Installation
You can install ChemGED using pip:

```bash
pip install chemged
```

## Usage
To use ChemGED, you just create an ``ApproximateChemicalGED`` object, and then call the
``compute_ged`` method with two chemical structures. They can be SMILES *or*
[RDKit](https://www.rdkit.org/docs/index.html) Mol objects.

```python
from chemged import ApproximateChemicalGED
ged_calc = ApproximateChemicalGED()

chemical1 = "CCO"  # SMILES of the first chemical
chemical2 = "CCN"  # SMILES of the second chemical

# you can use SMILES strings directly
approx_ged = ged_calc.compute_ged(chemical1, chemical2)

# you can also use RDKit Mol objects
from rdkit.Chem import MolFromSmiles
approx_ged = ged_calc.compute_ged(MolFromSmiles(chemical1), MolFromSmiles(chemical2))
```
ChemGED also implements ``pdist`` and ``cdist`` functions to compute pairwise distances between
sets of chemicals. These will return as Numpy arrays.

> [!NOTE]
> ``pdist`` will return the vector-form distance vector, while ``cdist`` will return a
> square-form distance matrix. ``scipy.spatial.distance.squareform`` can be used to convert
> the vector-form distance vector to a square-form distance matrix.

```python
from chemged import pdist, cdist

# Create a list of chemicals
chemicals = ["CCO", "CCN", "CC", "C"]

# Compute pairwise distances
distances_vector = pdist(chemicals)
print(distances_vector)  # Vector form

# Compute all-vs-all distances
distances_matrix = cdist(chemicals, chemicals)
print(distances_matrix)  # Square form
```

## Documentation
You can read more detailed documentation in the docs folder.

## Implementation
The approach used here uses bipartite graph matching[[1]](#1), and most of its implementation in python
is based off scripts from https://github.com/priba/aproximated_ged/tree/master.
ChemGED uses [RDKit](https://www.rdkit.org/docs/index.html) to handle chemicals inside python.

## References
<a id="1">[1]</a>
Riesen, Kaspar, and Horst Bunke.
"Approximate graph edit distance computation by means of bipartite graph matching."
Image and Vision computing 27.7 (2009): 950-959