diff --git a/.nojekyll b/.nojekyll
index 0c1f1b4..ce314d0 100644
--- a/.nojekyll
+++ b/.nojekyll
@@ -1 +1 @@
-3c5e9d40
\ No newline at end of file
+783fc651
\ No newline at end of file
diff --git a/_quarto.yaml b/_quarto.yaml
index 9cfddd1..e71f0ed 100644
--- a/_quarto.yaml
+++ b/_quarto.yaml
@@ -8,8 +8,8 @@ project:
- "*.sh"
- "*.yaml"
website:
- title: "ns-rse"
- site-url: https://ns-rse.github.io/
+ title: "nshephard.dev"
+ site-url: https://blog.nshephard.dev/
description: "Software development in a Research Environment"
navbar:
right:
diff --git a/about-code.xml b/about-code.xml
index 03f122e..7e9759d 100644
--- a/about-code.xml
+++ b/about-code.xml
@@ -5,21 +5,21 @@
xmlns:dc="http://purl.org/dc/elements/1.1/"
version="2.0">
Setup is relatively straight-forward, head to https://pre-commit.ci and sign-in with your GitHub account and grant pre-commit.ci
access to your account.
Once you have granted access you can choose which repositories pre-commit.ci
has access to. It is possible to grant access to all repositories but I would recommend doing so on a per-repository basis so you know and are in control of what is happening across your repositories. If you have administration rights to organisation repositories these should be listed in the “Select repositories” pull-down menu.
When logged into pre-commit.ci
using your GitHub account you are presented with a page similar to the following which lists the accounts and any organisations that you have authorised pre-commit.ci
to access.
You can follow the links through to view the history of jobs run by pre-commit.ci
and whether they pass or fail. The page shows the current status and provides both Markdown and reStructured Text code for adding badges to your source documents (e.g. the Markdown badge can be added to your repositories top-level README.md
and the badge will be displayed on GitHub)
You can click through and see the results of a given run and when they pass they look similar to the output you would have seen when making commits locally.
But sometimes things will fail as shown below where the trailing-whitespace
hook failed and the file was modified. But since pre-commit.ci
corrects and pushes such changes automatically you can see at the bottom that these changes were pushed to the Pull Request from which the originated.
Once you have done this your CI/CD pipeline should show at the very start the .pre
stage…
…and you can click through on this to see the details of the pipeline. Note that it takes a while to run as it has to download and initialise all of the environments for each configured hook unlike pre-commit.ci
(this is akin to writing your own GitHub Action to run pre-commit
which would also have to download and initialise the environments).
remote
push to two different URLs so am revisiting the topic and perhaps writing a little more clearly on it.
@@ -260,24 +260,24 @@ No matching items
author = {Neil Shephard},
title = {Git {Remotes} {Revisited}},
date = {2024-02-17},
- url = {https://ns-rse.github.io//posts/git-remotes-revisited},
+ url = {https://blog.nshephard.dev//posts/git-remotes-revisited},
langid = {en}
}
Git and various forges such as GitHub GitLab are useful collaborative tools for version controlling, sharing and working collaboratively. Normally a repository resides on your local computer and it tracks a remote (often referred to as origin
)
I’m a big fan of pre-commit and have written about it before (see posts on pre-commit, pre-commit CI and pre-commit updating). This post discusses some of the hooks that I use and how to configure them.
@@ -855,12 +855,12 @@ No matching items author = {Neil Shephard}, title = {Pre-Commit : {Useful} {Hooks}}, date = {2023-05-07}, - url = {https://ns-rse.github.io//posts/pre-commit-hooks}, + url = {https://blog.nshephard.dev//posts/pre-commit-hooks}, langid = {en} }Setup is relatively straight-forward, head to https://pre-commit.ci and sign-in with your GitHub account and grant pre-commit.ci
access to your account.
Once you have granted access you can choose which repositories pre-commit.ci
has access to. It is possible to grant access to all repositories but I would recommend doing so on a per-repository basis so you know and are in control of what is happening across your repositories. If you have administration rights to organisation repositories these should be listed in the “Select repositories” pull-down menu.
When logged into pre-commit.ci
using your GitHub account you are presented with a page similar to the following which lists the accounts and any organisations that you have authorised pre-commit.ci
to access.
You can follow the links through to view the history of jobs run by pre-commit.ci
and whether they pass or fail. The page shows the current status and provides both Markdown and reStructured Text code for adding badges to your source documents (e.g. the Markdown badge can be added to your repositories top-level README.md
and the badge will be displayed on GitHub)
You can click through and see the results of a given run and when they pass they look similar to the output you would have seen when making commits locally.
But sometimes things will fail as shown below where the trailing-whitespace
hook failed and the file was modified. But since pre-commit.ci
corrects and pushes such changes automatically you can see at the bottom that these changes were pushed to the Pull Request from which the originated.
Once you have done this your CI/CD pipeline should show at the very start the .pre
stage…
…and you can click through on this to see the details of the pipeline. Note that it takes a while to run as it has to download and initialise all of the environments for each configured hook unlike pre-commit.ci
(this is akin to writing your own GitHub Action to run pre-commit
which would also have to download and initialise the environments).
remote
push to two different URLs so am revisiting the topic and perhaps writing a little more clearly on it.
@@ -260,24 +260,24 @@ No matching items
author = {Neil Shephard},
title = {Git {Remotes} {Revisited}},
date = {2024-02-17},
- url = {https://ns-rse.github.io//posts/git-remotes-revisited},
+ url = {https://blog.nshephard.dev//posts/git-remotes-revisited},
langid = {en}
}
Git and various forges such as GitHub GitLab are useful collaborative tools for version controlling, sharing and working collaboratively. Normally a repository resides on your local computer and it tracks a remote (often referred to as origin
)
Setup is relatively straight-forward, head to https://pre-commit.ci and sign-in with your GitHub account and grant pre-commit.ci
access to your account.
Once you have granted access you can choose which repositories pre-commit.ci
has access to. It is possible to grant access to all repositories but I would recommend doing so on a per-repository basis so you know and are in control of what is happening across your repositories. If you have administration rights to organisation repositories these should be listed in the “Select repositories” pull-down menu.
When logged into pre-commit.ci
using your GitHub account you are presented with a page similar to the following which lists the accounts and any organisations that you have authorised pre-commit.ci
to access.
You can follow the links through to view the history of jobs run by pre-commit.ci
and whether they pass or fail. The page shows the current status and provides both Markdown and reStructured Text code for adding badges to your source documents (e.g. the Markdown badge can be added to your repositories top-level README.md
and the badge will be displayed on GitHub)
You can click through and see the results of a given run and when they pass they look similar to the output you would have seen when making commits locally.
But sometimes things will fail as shown below where the trailing-whitespace
hook failed and the file was modified. But since pre-commit.ci
corrects and pushes such changes automatically you can see at the bottom that these changes were pushed to the Pull Request from which the originated.
Once you have done this your CI/CD pipeline should show at the very start the .pre
stage…
…and you can click through on this to see the details of the pipeline. Note that it takes a while to run as it has to download and initialise all of the environments for each configured hook unlike pre-commit.ci
(this is akin to writing your own GitHub Action to run pre-commit
which would also have to download and initialise the environments).
If you use Python heavily you will likely be familiar with Virtual Environments. These provide isolated installs of specific packages that take precedence over any packages installed at the system level. There are lots of tools and frameworks for working with virtual environments such as venv
, virtualenv
and Conda. This post introduces and shows some of the features of virtualenvwrapper.
I’ve written before about Python Packaging and pre-commit which I’m a big fan of. Today I discovered a really useful tool for checking your packaging configuration and pre-commit configuration from the Scientific Python Development Guide.
This post describes steps in creating a Python package. If you are looking for information on installing packages this is done using Python PIP.
@@ -1477,11 +1477,11 @@ No matching items author = {Neil Shephard}, title = {Python {Packaging}}, date = {2023-03-25}, - url = {https://ns-rse.github.io//posts/python-packaging}, + url = {https://blog.nshephard.dev//posts/python-packaging}, langid = {en} }