Parms with Arrays

At this moment in time April, 2025, the preferred way to authorize publishing a Python package to PYPI.org is to use tokens, twine and a trusted publisher.  For my simple project and my limited skills at setting up a git workflow that will publish when a tag is created,  the preferred workflow is a bit much. 

For my small projects, I have been using twine and a .pypirc file.

the .pypirc file looks like:

#
# Test: py -m twine upload --repository testpypi dist/*
# Prod: py -m twine upload --repository pypi dist/*
#


[distutils]
index-servers =
    pypi
    testpypi

[pypi]
repository = https://upload.pypi.org/legacy/

[testpypi]
repository = https://test.pypi.org/legacy/

And the command to publish the package (using uv) is :

    uv run twine upload --repository testpypi dist/*

All works well, but the .pypirc file is being deprecated because it requires storing tokens in plain text.  The new recommended way is to use the credential manager built into the OS – Linux, Windows and Mac.

Using a Windows OS, open the credential manager from the control panel, select the Windows Credentials tab and scroll down to the Generic Credentials. and click on Add a generic credential. This will prompt for:
Internet or network address:   (put your website address here)
User name:  (enter __token__ )
Password:  (enter the token value)

Save this and it should work.  Twine will check the credential manager using the website url and the username __token__.  The website url is based on the –repository option: pypi or testpypi and seems to be built into the twine package.

This works in the case where you just have one token for all your python projects.  But if you need a scoped token that is tied to a single project, then you need a mechanism that will map to the project specific token.

At this point, the solution I have found is to use the .pypirc file to map a custom –repository option to the unique url for the project. 

Assuming you have a package mycoolpackage.  

The .pypirc file, which is in the user root directory:

[distutils]
index-servers =
    pypi
    testpypi
    testpypi-mycoolpackage
    pypi-mycoolpackage

[pypi]
repository = https://upload.pypi.org/legacy/

[testpypi]
repository = https://test.pypi.org/legacy/

[testpypi-mycoolpackage]
repository = https://test.pypi.org/project/mycoolpackage

[pypi-mycoolpackage]
repository = https://upload.pypi.org/project/mycoolpackage

The upload to test:
    uv run twine upload --repository testpypi-mycoolpackage dist/*

Thee upload to production:
    uv run twine upload --repository pypi-mycoolpackage dist/*

It all feels a bit clunky to me, but it is working for now.  

Using git as a source code manager, whenever I need to update a plugin, it is a challenge as I never remember the svn commands. And when I upgraded my computer, I opted not to install svn with the idea of just using git and git svn command.

The workflow is generally:

• clone the svn repo into git — this is usually done once
• Update the readme in the stable tag and trunk to reflect the tested thru version of WP
• Update the plugin and create a new stable release.

Clone the SVN repo to Git

Before starting get the earliest revision number for your plugin.  This can be found on the plugin page, under the Development tab.  There is a link to the Development Log which will show all the revisions.  Note the initial revision number.

<plugin name> => replace with the plugin name, do not wrap the plugin name in <>

-r xxxxx => this is the revision number, replace xxxx with the number from above.

Create the local git repo from the wordpress svn repo.  The following command will create a new directory with the name of the plugin:

git svn clone --stdlayout -r xxxx https://plugins.svn.wordpress.org/<plugin name>

Change directories to the local git repo

cd <plugin name>

Confirm the git config has the svn-remote paths to trunk, branches, tags:

git config -l

git branch -r (shows origin/trunk)

Now the long part.  Fetch all the history from the svn repository.  The log-window-size options sets the read buffer.  The default is 100 and 1000 is faster for my configuration.

git svn fetch --log-window-size=1000

git branch -r  (shows trunk, branches, tags)

Update the Readme on the Stable Tag

To update the readme to show the correct tested thru WP version (or any chnange that is not a new release), 

• checkout the stable tag
• make the change
• push to svn

git branch -r  (shows trunk, branches, tags)

git checkout origin/tags/<stable tag>  (headless)

Make your changes

git commit -am"update tested up to value => 6.0"

git svn dcommit     (push to svn stable tag)

Now the trunk & master are out of sync with the tag.  Create a git temp-tag branch, merge it to the master and push the git master branch to the svn trunk.  Then delete the temp-tag branch

git switch -c <git temp branch name>

git checkout master

Sync the master with the updated stable tag

git merge temp-tag

Sync the trunk with the stable tag (main branch should be tracking to svn trunk)

git svn dcommit

Now clean up the leftover temp tag branch in git.  If you need the current trunk or tag, just do another git checkout origin/trunk or /tags/xxxx

git branch -d temp-tag

Update the plugin and create a new stable tag

This section provides the steps to update a plugin code base and push the changes to svn as a new stable tag.

• in git make the changes
• merge changes to main branch
• push the changes to svn
• push the trunk to the new stable tag

Assuming all the changes have been merged to the main branch,  the following will push the main branch changes to trunk and then create the new stable tag.

View the existing local svn branches

git branch -r  (shows trunk, branches, tags)

git switch main

git checkout -b new-functionality

make changes and commit changes

Merge the changes to master, with –squash to remove intermittent commits from master & ultimately svn

git checkout master

git merge new-functionality --squash       

Run the dcommit with -n to verify it is pointing to the correct url
git svn dcommit -n
git svn dcommit -n --commit-url https://plugins.svn.wordpress.org/<plugin-name>/trunk

git svn dcommit     (push changes to svn trunk)

While in the git main branch, create the new stable tag.  This may run a long time in Windows.

git svn branch -t 1.0.9           (where 1.0.9 is the tag name)

And clean up the leftover new-functionality branch in git. 

git branch -d new-functionality

Errors while running dcommit

Merge Conflict

If a CONFLICT is encountered during the git svn dcommit, a message like the following will appear.

CONFLICT (content): Merge conflict in readme.txt
error: could not apply 783e0b2... add nonce to fix csrf vulnerability
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".

To resolve this, open the file identified in the the CONFLICT line in your editor, resolve the conflict and then
git add <file name>
git rebase --continue

This should complete the dcommit

File out of date

If an error like the following is encountered:

ERROR from SVN:
Item is out of date: File '/<plugin-name>/trunk/<filename>' is out of date

then save the changes from master in a new git branch, switch to master, rebase master from origin/trunk, then dcommit from master:

git checkout -b save-master changes 

git switch master

git rebase origin/trunk

git svn dcommit -n        (make sure committing to svn trunk)

git svn dcommit

After confirming all the changes are in the svn repo, clean up the git repo by deleting the save-master-changes

*** these notes are a work-in-progress and will be updated as needed ***

This post documents how I set up projects in Python and how to configure VS Code for debugging.

Project Structure

There are 2 basic forms of project structure that seem to work for me.

Simple Projects

project-name
    doc/
    data/
    inc/
        __init__.py
        shared-code1.py
        shared-code2.py
    tests/
        __init__.py
        test_test1.py
        test_test2.py
    program.py
    program2.py

Complex Projects

This is my preferred setup.

project-name
    doc/
    data/    
    tests/
        testfiles/
            temp&permanent-test-files
        __init__.py
        test_test1.py
        test_test2.py
    project-name
        inc/
            __init__.py
            shared-code1.py
            shared-code2.py
        __init__.py
        __main__.py
        program.py

Testing

The __init__.py in the testing folder should contain the following code.  This adds the project folder to the python path so the imports work as expected.

import os
import sys
PROJECT_PATH = os.getcwd()
PROJECT_FOLDER = os.path.basename(PROJECT_PATH)
SOURCE_PATH = os.path.join(
    PROJECT_PATH,PROJECT_FOLDER
)
sys.path.append(SOURCE_PATH)

VS Code Configuration

The challenge with both of these structures is importing the programs and shared programs in the tests modules. If you are in the main directory, then running the tests with discovery (ie python -m unittest) will generally work. However, if you are in the test directory and trying to debug a test with VS Code, the imports fail with module not found.

The following options in the project.code-workspace will set the PYTHONPATH to the workspace folder so all imports can be found. The PYTHONPATH must be updated in two locations: (1)settings and (2) launch.

Note:  The /project-name is only needed for the complex project setup.

{
 "folders": [
    {
	"path": "."
    }
 ],
 "settings": {
    "python.linting.cwd": "${workspace}/project-name",
    "python.analysis.extraPaths": [
		"${workspaceFolder}/project-name"
		],
    "terminal.integrated.cwd": "${workspaceFolder}",
    "terminal.integrated.env.windows": {
	"PYTHONPATH": "${workspaceFolder}/project-name",
		},
    "terminal.integrated.env.linux": {
	"PYTHONPATH": "${workspaceFolder}/project-name",
		},
 },
 "launch": {
	"version": "0.2.0",
	"configurations": [
	  {
	    "name": "Python: Current File",
	    "type": "python",
	    "request": "launch",
	    "program": "${file}",
	    "env": {"PYTHONPATH": "${workspaceFolder}/project-name"},
	    "console": "integratedTerminal",
	    "justMyCode": true,
            "cwd": "${workspaceFolder}",
	  }

        ]
 }
}

WSL

With Windows and WSL, I have a .bashrc modification which opens the bash terminal in my data directory when the terminal is opened from the command line.  The code snippet below ignores the change directory command when a terminal is opened from VS Code.

# start in data directory if not vs code
if [ "$TERM_PROGRAM" != "vscode" ]; then
    cd /mnt/c/Data
fi

This is the product custom post type

this is a sample of the news custom post type