devel/py-flexparser: Add py-flexparser 0.4
Why write another parser? I have asked myself the same question while working on this project. It is clear that there are excellent parsers out there, but I wanted to experiment with another way of writing them. The idea is quite simple. You write a class for every type of content (called here ParsedStatement) you need to parse. Each class should have a from_string constructor. We used the typing module extensively to make the output structure easy to use and less error-prone.
This commit is contained in:
@@ -5012,6 +5012,7 @@
|
||||
SUBDIR += py-flex
|
||||
SUBDIR += py-flexcache
|
||||
SUBDIR += py-flexmock
|
||||
SUBDIR += py-flexparser
|
||||
SUBDIR += py-flit
|
||||
SUBDIR += py-flit-core
|
||||
SUBDIR += py-flit-scm
|
||||
|
||||
@@ -0,0 +1,24 @@
|
||||
PORTNAME= flexparser
|
||||
PORTVERSION= 0.4
|
||||
CATEGORIES= devel python
|
||||
MASTER_SITES= PYPI
|
||||
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
|
||||
|
||||
MAINTAINER= sunpoet@FreeBSD.org
|
||||
COMMENT= Parsing made fun ... using typing
|
||||
WWW= https://github.com/hgrecco/flexparser
|
||||
|
||||
LICENSE= BSD3CLAUSE
|
||||
LICENSE_FILE= ${WRKSRC}/LICENSE
|
||||
|
||||
BUILD_DEPENDS= ${PYTHON_PKGNAMEPREFIX}setuptools>=61:devel/py-setuptools@${PY_FLAVOR} \
|
||||
${PYTHON_PKGNAMEPREFIX}setuptools-scm>=3.4.3:devel/py-setuptools-scm@${PY_FLAVOR} \
|
||||
${PYTHON_PKGNAMEPREFIX}wheel>=0:devel/py-wheel@${PY_FLAVOR}
|
||||
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}typing-extensions>=0:devel/py-typing-extensions@${PY_FLAVOR}
|
||||
|
||||
USES= python
|
||||
USE_PYTHON= autoplist concurrent pep517
|
||||
|
||||
NO_ARCH= yes
|
||||
|
||||
.include <bsd.port.mk>
|
||||
@@ -0,0 +1,3 @@
|
||||
TIMESTAMP = 1779222882
|
||||
SHA256 (flexparser-0.4.tar.gz) = 266d98905595be2ccc5da964fe0a2c3526fbbffdc45b65b3146d75db992ef6b2
|
||||
SIZE (flexparser-0.4.tar.gz) = 31799
|
||||
@@ -0,0 +1,8 @@
|
||||
Why write another parser? I have asked myself the same question while working on
|
||||
this project. It is clear that there are excellent parsers out there, but I
|
||||
wanted to experiment with another way of writing them.
|
||||
|
||||
The idea is quite simple. You write a class for every type of content (called
|
||||
here ParsedStatement) you need to parse. Each class should have a from_string
|
||||
constructor. We used the typing module extensively to make the output structure
|
||||
easy to use and less error-prone.
|
||||
Reference in New Issue
Block a user