To help you get started, we've collected the most common ways that vcard is being used within popular public projects.

l0b0 / vcard / tests / test_package.py View on Github

def test_valid(self):
        """Valid (but not necessarily sane) vCards"""
        for vcard_file in VCARDS_VALID:
            vcard_text = _get_vcard_file(vcard_file)
            if vcard_text is None:
                continue

            try:
                with warnings.catch_warnings(record=True):
                    vc_obj = vcard_validator.VCard(vcard_text, filename=vcard_file)
                self.assertNotEqual(vc_obj, None)
            except vcard_errors.VCardError as error:
                error_message = '\n\n'.join((
                    'Expected valid vCard for {vcard_file!r}, but it failed to validate'.format(
                        vcard_file=vcard_file
                    ),
                    str(error)
                ))
                self.fail(error_message)

View more ways to use vcard

vCard module

This program can be used for strict validation and parsing of vCards. It currently supports vCard 3.0 (RFC 2426).

Installation

To install or upgrade in a virtualenv:

pip install --upgrade vcard

To use without installing:

nix-shell

See the nixpkgs index for instructions to install the command-line tool or the Python package.

Usage

See vcard --help.

Utilities

• format-TEL.bash - Format phone numbers according to national standards
• split.bash - Split a multiple vCards file into individual files
• sort-lines.bash - Sort vCard property lines according to a custom key
• join-lines.sh - Join previously split vCard lines
• split-lines.sh - Split long vCard lines

Packaging status

Development

Setup

git clone git@gitlab.com:engmark/vcard.git

Release

1. Bump the version in vcard/version.txt
2. Commit & push everything
3. Create a new merge request
4. Wait for the MR to be merged
5. Update to latest master
6. nix-shell --pure --run './clean.bash && ./distribute.bash && ./release.bash'

Requirements:

• Nix

Contributing code

You can contribute either by submitting a merge requests or by email.

Security fixes should only be submitted via email, encrypted with the PGP key F1C5F63013E5DE2FB574D42ACE5EB38344D85DB6.

Email is also appropriate in some other cases:

• If you don't want to create a GitLab account.
• If you want to be anonymous. Make sure to be explicit about this! Contributing anonymously means the following:
  • You transfer copyright to me. Otherwise your contribution would make it impossible for future maintainers to ever change the license - they wouldn't know who to contact to ask for permission.
  • The commit message will make it clear that it was contributed anonymously, with an "Authored-by: Anonymous <>" line.
• Email submissions must be in patch format, including a detailed commit message, so that it can be added to the repository without any changes, and without breaking the pipeline.

🚫 Other channels are not supported.

How open is this project?

Background

• GitLab features:
  • All features enabled for this repository are publicly available
  • Project settings are private for security reasons
• Commit history:
  • All commits on all branches are publicly visible
• Issues:
  • Publicly visible
  • You need to be logged into GitLab to submit an issue or comment
  • Questions from non-users interested in the project are welcome
  • Expect answers within a few days
• Pipelines:
  • The configuration is publicly visible
  • Runs are publicly visible
  • Logs are publicly visible, and logs should be kept indefinitely.
• Releases:
  • Hosted publicly
  • Old releases should be available indefinitely, but this is under PyPI's control, not mine
• Work (past, current, and planned) is documented publicly within the project