so far i get the computers for a user (sometimes singular, sometimes multiple), but im trying to figure out the appropriate api.put command for it.

i usually work in bash so i know there the command ends with "<computer_group><computer_additions>$serial</computer_additions></computer_group>" https://JSS.jamfcloud.com/JSSResource/computergroups/id/{id} -X PUT >", but now sure how to translate it to python.

Issue

Testing the stable docker version of python-jamf and the build process is failing at network creation.

Steps to reproduce

Have only tried with python-jamf-github, but suspect it's the same for python-jamf-dev.

$ cd python-jamf/python-jamf-docker
$ docker-compose run --rm python-jamf-github
network jamfpro_jamfnet declared as external, but could not be found

Workaround

Create the jamfpro_jamfnet docker network manually.

$ docker network create -d bridge jamfpro_jamfnet
4576<snip>
$ docker-compose run --rm python-jamf-github
[+] Building 106.1s (6/8)
 => [internal] load build definition from Dockerfile                                                                                                                            0.0s

For your consideration, this pull request applies Python Black formatting.

Benefits

In the projects I've worked on, I've found that applying consistent autoformatting (whether Black or something similar like autopep8 or yapf) significantly streamlines contributions. Discussions about code style fade away, allowing contributors to focus on the function.

Also, Black's tendency to split long lines up slightly reduces the risk of merge conflicts if multiple elements of the same list/tuple/dict are edited by two different PRs.

Black sometimes also surfaces syntax bugs before commit, since the formatting won't run if the Python doesn't compile.

Risks

Because this PR touches almost every Python file in the project, it's likely that it will conflict with changes on contributors' branches downstream. Any contributors will need to rebase their changes on the main branch (and possibly resolve conflicts manually) in order to continue. (At the moment, I don't see any non-merged branches here on GitHub, so it's probably a good time for a change like this.)

The most streamlined way to use Black is to configure your local development environment with it, so that every time you save, the formatting is applied. In my VSCode prefs, I have settings to facilitate this:

"python.formatting.provider": "black",
"python.formatting.blackPath": "/opt/homebrew/bin/black",

This optional streamlining creates a small additional setup burden for people who are regularly contributing, but shouldn't prevent those who wish to contribute more casually.

Output

The changes in this PR were produced with black ., resulting in the output below. No changes to actual function were made.

% black .
reformatted jamf/convert.py
reformatted jamf/version.py
reformatted setup.py
reformatted jamf/config.py
reformatted jamf/setconfig.py
reformatted jamf/api.py
reformatted tests/api_mock_test.py
reformatted tests/convert_json_xml_test.py
reformatted tests/test_package.py
reformatted tests/test_config.py
reformatted jamf/admin.py
reformatted jamf/package.py
reformatted tests/test_records.py
reformatted jamf/records.py
All done! ✨ 🍰 ✨
14 files reformatted, 2 files left unchanged.

For more context, see this portion of my 2019 PSU MacAdmins talk, which covers Black specifically.

Thanks for considering!

Not really an issue. Just a point I wanted to raise for discussion. The README is now getting to a length and if I add documentation for my work it will get longer.

So how do you feel about me taking the existing README and my documentation and turning it onto a shorter README and a wiki? I was thinking of just a top page and only one layer of sub pages corresponding with the current headlines.

I also have no idea if I can PR the wiki but I'm guessing I can.

SMB could be supported using pysmb (without subprocess calls) I'm not sure about AFP though.

We could also use 'mount' for linux machines (but then im unsure about other bsd distros)

This pull request creates a pre-commit configuration and GitHub Actions job that runs it upon submitting PRs or pushing to main. The configuration includes two major formatting automations:

• Python Black: The project already uses Black manually; adding a pre-commit and CI config makes this formatting easier for contributors to adopt and ensures standard style for submitted pull requests
• iSort: Sorts Python imports in a consistent way, slightly reducing chances of merge conflict

The above two changes will result in a new commit being made to the codebase automatically once merged. The changes will be to style only, and should not affect function at all. Here is a preview of that commit.

I've included a few other relatively minor checks. The codebase already complies with all of these, so no changes are needed for these.

• check-added-large-files: Helps prevent accidentally committing binary or image files to the repo by limiting new files to 100KB.
• fix-byte-order-marker: Ensures files have consistent byte order markers (e.g. after being edited by a contributor using Windows)
• check-case-conflict: Ensures no files are committed that would cause a conflict on case-insensitive file systems
• check-docstring-first: Ensures Python docstrings are in the proper place
• check-merge-conflict: Ensures no merge conflict markers are present in committed files
• mixed-line-ending: Forbids CRLF line endings

Once this is merged, it may be helpful to add a section to the jctl Contribute wiki page, between the "Clone the Forked Repository" and "Create a Feature Branch" sections:

### Install and enable pre-commit

Pre-commit is a framework that automatically runs linting and consistency checks before changes
are committed to the repository locally. For contributors who will be working in Python code, we
recommend [installing pre-commit](https://pre-commit.com/#install) and running `pre-commit install`
in the repo to activate these checks.

(Note that even if contributors don't install pre-commit locally, GH Actions will run the checks upon submitting PRs and fix what it can.)

On the AutoPkg project, we made a similar change recently, and it's worked well.

The README section on testing was seriously wrong. I also attempted (and failed) to fix a problem where test_records.py won't run the tests if called on its own. It does run the tests if you use discovery. Not sure if it's worth opening an issue on it, but if you do assign it to me.

I figured out why python3 -m unittest discover -v wasn't working. When we moved tests out of jamf and put them on the same level in python-jamf the imports tried to import from a parent that didn't exist.

So all the from .. import <package> had to be changed to from jamf import <package>

Tomorrow I will see about fixing the 9 tests that error.

Hi:

Jamf will deprecate support for Basic Authentication in Jamf Pro v10.35.0 or later. python-jamf will need to add support for Bearer Token authentication by implementing a version check of Jamf Pro, your application can determine whether Bearer Token authentication is supported (v10.35.0 or later) or if use of Basic authentication is required (v10.34.0 and earlier).

The jamf-pro-version endpoint within the Jamf Pro API returns the version of the Jamf Pro Server, to help your application determine authentication compatibility with a given Jamf Pro Server. Jamf recommends including a preference to allow users to select the authentication schema based on their environment configuration or dynamically determining which authentication mechanism to use based on the Jamf Pro Server version.

In addition to the recommendations provided above, Jamf has updated the Classic API Postman Collection to now default to the use of Bearer Token authentication. Older versions of the collection will continue to be available for interaction with environments not yet upgraded to 10.35.0 or later, however the new collection will default to using Bearer Token authentication.

Additional details regarding the changes, including best practices are detailed on the Jamf Developer Portal.

Output looks like this.

./jctl packages -S view_included

BBEdit-13.5.5.pkg Policies Install Bare Bones BBEdit PatchSoftwareTitles Bare Bones BBEdit - 13.5.5 PatchPolicies 13.5.5 SS

BBEdit-13.5.6.pkg

Xcode-11.3.1.pkg Policies Install Xcode 11.3 (macOS 10.15) ComputerGroups 02 - Needs Xcode-11.3.1.pkg (Staff, Student, Opt-In, 10.15)

Zoom-5.6.4.765.pkg Policies Install Zoom Client for Meetings

./jctl scripts -S script_contents #!/usr/bin/perl -w

use strict;

print "Hi mom";

"Elektra stores configuration in a global, hierarchical key database."

https://www.libelektra.org/plugins/python

Should be this easy.

import kdb
kdb.Key("user:/jamf_server")
kdb.Key("user:/jamf_username")

test_package has six tests failing. All appear to be failing because the path passed to tar in a call to get package information points to the actual package and not the the expanded package so tar barfs on it.