All posts with the tag "markata"
I was looking back at my analytics page today and wondered what were my posts about back at the beginning. My blog is managed by markata so I looked at a few ways you could pull those posts up. Turns out it’s pretty simple to do, use the markata map with a filter.
from markata import Markata
m.map('title, slug, date', filter='date.year==2016', sort='date')
Note
the filter is python eval that should evaluate to a boolean, all of the
attributes of the post are available to filter on.
[
('⭐ jupyterlab jupyterlab', 'jupyterlab-jupyterlab', datetime.date(2016, 12, 13)),
('⭐ nickhould tidy-data-python', 'nickhould-tidy-data-python', datetime.date(2016, 12, 9)),
(
'⭐ mikeckennedy write-pythonic-code-demos',
'mikeckennedy-write-pythonic-code-demos',
datetime.date(2016, 11, 22)
),
(
'⭐ mikeckennedy write-pythonic-code-for-better-data-science-webcast',
'mikeckennedy-write-pythonic-code-for-better-data-science-webcast',
datetime.date(2016, 11, 22)
),
('⭐ rajshah4 dlgroup', 'rajshah4-dlgroup', datetime.date(2016, 11, 18)),
('⭐ pandas-dev pandas', 'pandas-dev-pandas', datetime.date(2016, 10, 5))
]
You could use the list command as well right within your shell and the same
map and filters work.
⬢ [devtainer-0.1.3] ❯ markata list --map title --filter='date.year==2016'
[22:35:06] 2088/2145 posts skipped skip.py:36
57/2145 posts not skipped skip.py:37
⭐ pandas-dev pandas
⭐ rajshah4 dlgroup
⭐ mikeckennedy write-pythonic-code-for-better-data-science-webcast
⭐ mikeckennedy write-pythonic-code-demos
⭐ nickhould tidy-data-python
⭐ jupyterlab jupyterlab
You could also do it with jin right inside of a markdown post using the jinja_md plugin.
{% raw %}
{% for title, slug, date in markata.map('title, slug, date', filter='date.year==2016', sort='date') %}
* [{{title}}]({{slug}}) - {{date}}
{% endfor %}
{% endraw %}
Note
You do have to `jinja: true` in the frontmatter of the post.
{% for title, slug, date in markata.map(’title, slug, date’, filter=‘date.year==2016’, sort=‘date’) %}
I just implemented a latest blog post link in Markata by asking for the first post slug from the blog feed. The implementation uses the jinja_md plugin to render jinja against the markdown and a tag to redirect.
My latest blog post is [[ {{ markata.feeds.blog.posts[0].slug }} ]]. Click the
link if you are not automatically redirected.
<meta http-equiv="Refresh" content="0; url='/{{ markata.feeds.blog.posts[0].slug }}'" />
Feeds are setup in markata.toml configuration. They provide a handy way to
create an html feed, rss feed, and quickly reference a filtered set of posts
like this.
# you will need to enable the jinja_md plugin along with the defaults
[markata]
hooks = [
"markata.plugins.jinja_md",
"default",
]
# set up the blog feed
[[markata.feeds]]
slug = 'blog'
template = "feed.html"
filter = "date<=today and templateKey in ['blog-post'] and published"
sort = "date"
reverse = true
For more information on markata check out the full markata post.
Markata now allows you to create jinja extensions that will be loaded right in
with nothing more than a pip install.
The entry for 0.5.0.dev2 from markata’s changelog
The first example that you can use right now is markata-gh. It will render
repos by GitHub topic and user using the gh cli, which is available in github
actions!
Get it with a pip install
pip install markata-gh
Use it with some jinja in your markdown.
## Markata plugins
It uses the logged in uer by default.
{% gh_repo_list_topic "markata" %}
You can more explicitly grab your username, and a topic.
{% gh_repo_list_topic "waylonwalker", "personal-website" %}
The jinja extension details are for another post, but this is how markata-gh
exposes itslef as a jinja extension.
class GhRepoListTopic(Extension):
tags = {"gh_repo_list_topic"}
def __init__(self, environment):
super().__init__(environment)
def parse(self, parser):
line_number = next(parser.stream).lineno
try:
args = parser.parse_tuple().items
except AttributeError:
raise AttributeError(
"Invalid Syntax gh_repo_list_topic expects <username>, or <username>,<topic> both must have the comma"
)
return nodes.CallBlock(self.call_method("run", args), [], [], "").set_lineno(
line_number
)
def run(self, username=None, topic=None, caller=None):
"get's markdown to inject into post"
return repo_md(username=username, topic=topic)
Then markata-gh exposes itself as an extension through entrypoints.
If your project is using pyproject.toml for packaging you can setup an
entrypoint as follows.
[project.entry-points."markata.jinja_md"]
markta_gh = "markata_gh.repo_list:GhRepoListTopic"
If your project is using setup.py for packaging you can setup an
entrypoint as follows.
setup(
...
entry_points={
"markata.jinja_md": ["markta_gh" = "markata_gh.repo_list:GhRepoListTopic"]
},
...
)
Markata now uses hatch as its build backend, and version bumping tool.
setup.py, and setup.cfg are completely gone.
Markata 0.5.0 is now out, and it’s huge. Even though it’s the backend of this blog I don’t actually have that many posts directly about it. I’ve used it a bit for blog fuel in generic ways, like talking about pluggy and diskcache, but very little have I even mentioned it.
Over the last month I made a big push to get 0.5.0 out, which adds a whole
bunch of new configurability to markata.
Here’s the changelog entry.
- Moved to PEP 517 build #59 0.5.0.dev1
Before cutting all of my personal projects over to hatch. The first thing I did was to setup a solid github action, hatch-actionthat I can resue.
It automatically bumps versions, using pre-releases on all branches other than main, with special branches for bumping major, minor, patch, dev, alha, beta, and dev.
To convert the project over to hatch, and get rid of setup.py/setup.cfg, I ran
hatch new --init. This automatically grabs all the metadata for the project
and makes a pyproject.toml that has most of what I need.
hatch new --init
I then manually moved over my isort config, put flake8 config into .flake8,
and dropped setup.cfg.
Part of my hatch-action is to run a before-command, for markata, this runs
all of my linting and testing in one hatch script called lint-test. If this
fails CI will fail and I can read the report in the logs, make a fix and
re-publish.
[tool.hatch.envs.default.scripts]
cov = "pytest --cov-report=term-missing --cov-config=pyproject.toml --cov=markata --cov=tests"
no-cov = "cov --no-cov"
lint = "flake8 markata"
format = "black --check markata"
sort-imports = "isort markata"
build-docs = "markata build"
lint-test = [
"lint",
"format",
"seed-isort-config",
"sort-imports",
"cov",
]
test-lint = "lint-test"
with automatic versioning
My typical workflow is to work on features in their own branch where they do
not automatically version or publish, they keep the same version they were
branched off of. Then I do a pr to develop, which will do a minor,dev bump
and publish a pre-relese to pypi.
# starting with version 0.0.0
Feature1 -- │
Feature2 -- ├── dev 0.1.0.dev1,2,3 ── main 0.1.0
Feature3 -- │
I will let several features collect in develop before cutting a full relese over to main. This gives me time to make sure the solution is what makes the most sense, I try to use it in a few projects, and generally its edges show, and another pr is warranted to make the feature useful for more use cases. After running and using these new releases in a few projects, I am confident that its ready and release to main.
Doing PR’s with gh, probably deserves its own post but here are some helpful commands.
gh pr create --base develop --fill
gh pr edit
gh pr diff | dunk
gh pr merge -ds
hatch makes building and publishing pretty straightforward. It’s one command inside my hatch-action to build and one to publish. On each project that uses my hatch-action I only need to give it a token that I get from PyPi.
env:
HATCH_INDEX_USER: __token__
HATCH_INDEX_AUTH: ${{ secrets.pypi_password }}
If you want to see all of the details on how markata moved over to hatch, you can check out this diff.
https://github.com/WaylonWalker/markata/compare/v0.4.0..v0.5.0.dev0
A long needed feature of markata has been the ability to really configure out templates with configuration rather. It’s been long that you needed that if you really want to change the style, meta tags, or anything in the head you needed to write a plugin or eject out of the template and use your own.
Now you can add some extra style to your site with the existing built-in template.
[[markata.head]]
text = """
<style>
img {
width: 100%;
height: auto;
}
ul {
display: flex;
flex-wrap: wrap;
}
</style>
"""
Each text entry in markata.head just gets appended raw into the head.
[[markata.head]]
text = """
<style>
img {
width: 100%;
height: auto;
}
ul {
display: flex;
flex-wrap: wrap;
}
</style>
"""
[[markata.head]]
text = """
<script>
console.log('hey there')
</script
"""
If this does not take you far enough yet, you can still eject out and use your own template pretty easy. If you are going for a full custom site it’s likely that this will be the workflow for awhile. Markata should only get better and make this required less often as it matures.
[markata]
post_template = "pages/templates/post_template.html"
Once you have this in your markata.toml you can put whatever you want in your
own template.
Markata is a great python framework that allows you to go from markdown to a full website very quickly. You can get up and running with nothing more than Markdown. It is also built on a full plugin architecture, so if there is extra functionality that you want to add, you can create a plugin to make it behave like you want.
Full transparancy… I built markata.
The talk is live on YouTube. Make sure you check out the other videos from the conference. There were quite a few quality talks that deserve a watch as well.
a sprinter edging out his opponent by Dall-e
It’s about time to release Markata 0.3.0. I’ve had 8 pre-releases since the
last release, but more importantly it has about 3 months of updates. Many of
which are just cleaning up bad practices that were showing up as hot spots on
my pyinstrument reports
Markata started off partly as a python developer frustrated with using nodejs for everything, and a desire to learn how to make frameworks in pluggy. Little did I know how flexible pluggy would make it. It started out just as my blog generator, but has turned into quite a bit more.
Over time this side project has grown some warts and some of them were now becoming a big enough issue it was time to cut them out.
I like to use my tils articles for examples and tests like this as there are enough articles for a good test, but they are pretty short and quick to render.
mkdir ~/git/tils/tils
cp ~/git/waylonwalker.com/pages/til/ ~/tils/tils -r
cd ~/git/tils/tils
At the time of writing this is the current version of markata, so just make a new venv and run it.
python3 -m venv .venv --prompt $(basename $PWD)
pip install markata
markata clean
markata build
cold tils: 14.523 warm tils: 1.028
python3 -m venv .venv --prompt $(basename $PWD)
# --pre installs pre-releases that include a b in their version name
pip install markata --pre
markata clean
markata build
cold tils: 11.551 (+20%) warm tils: 0.860 (+16%)
These measurements were taken with pyinstrument mostly out of convenience since there is already a pyinstrument hook built in, but also because I like pyinstrument.
Here is the pyinstrument report from the last run.
This comparison was not very exhaustive. It was ran on my pretty new to me Ryzen 5 3600 machine.
Most of these changes revolve in how the lifecycle is ran. It was trying to be extra cautious and run previous steps for you if it thought it might be needes, in reality it was rerunning a few steps multiple times no matter what.
The other thing I turned off by default, but can be opted into, is beautifulasoup’s prettify. That was one of the slower steps ran on my site.
It should be out by the time you see this, I wanted to compare the changes I had made and make sure that it was still making forward progress and thought I would share the results.