PyPI

[StoneyJackson]

If we distributed PLCC through PyPI then installing PLCC would become...

$ pip install plcc

And no one needs to set environment variables (e.g., LIBPLCC). All Python scripts can find the resource that they need (e.g., Std/) relative to their location (__file__). We might need to reimplement the PLCC scripts (e.g., parse, scan, etc.) in Python. This could have the added benefit of making them platform independent.

[jashelio]

It’s been a while since I used pip. Do you have to have super user permission to get pip to work?On Apr 21, 2024, at 9:39 AM, Stoney Jackson ***@***.***> wrote: If we distributed PLCC through PyPI then installing PLCC would become... $ pip install plcc And no one needs to set environment variables (e.g., LIBPLCC). All Python scripts can find the resource that they need (e.g., Std/) relative to their location (__file__). We might need to reimplement the PLCC scripts (e.g., parse, scan, etc.) in Python. This could have the added benefit of making them platform independent. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[StoneyJackson]

@jashelio Should be possible. Something like:

$ python3 -m pip install --user plcc

This I based on this: https://packaging.python.org/en/latest/tutorials/installing-packages/#installing-to-the-user-site

[AksharP5]

@StoneyJackson

Everything I have learned about how to package to PyPi, and what I have so far:

1. Create an account on PyPi
2. Verify account
3. Create a setup.py file in the root
4. pip install setuptools
5. Fill setup.py out with required information, this is what I have so far for this, may need to be altered:

from setuptools import setup

with open('README.md') as f:
    long_description = f.read()

setup(
    name='plcc',
    version='7.0.0',
    description='A Programming Language Compiler Compiler',
    long_description=long_description,
    long_description_content_type='text/markdown',
    url='https://github.com/ourPLCC/plcc',
    author="Akshar Patel", #placeholder name
    author_email='aksharcommit@gmail.com', #placeholder email
    license='GPL 3',
    # Derived requirements from pip3 freeze, but some of these may or may not be needed, and additional ones may be missing
    install_requires=[
        'argcomplete==3.3.0',
        'click==8.1.7',
        'pipx==1.5.0',
        'userpath==1.9.2'],
    classifiers=[
        'License :: OSI Approved :: GNU General Public License v3 (GPLv3)',
        'Operating System :: OS Independent',
        'Intended Audience :: Education', 
        'Programming Language :: Python',
        'Programming Language :: Python :: 3 :: Only',
        'Natural Language :: English',
        'Programming Language :: Java',
        'Programming Language :: Java :: 17'
    ] # May need to add more programming language classifiers as it states in the README.md that 
      # plcc works with python>=3.5 and java>=11

      # Can also add entrypoints here, basically map a command to a specific function in a file, will likely need to import the file 
      # in the __init__.py file, this could look something like this:
      # entry_points={
      #     'console_scripts': ['plcc=plcc.__main__.py:main']
      # }
)

4. pip3 install wheel (try --user if it doesnt work) - Needed for next step
5. python setup.py sdist bdist_wheel - Creates a build and dist folder
6. pip install --upgrade twine --user - Used to package and upload dist/ folder to pypi
7. twine upload dist/* - will ask for the pypi account credentials
8. Package should be available to download via pip3 after these steps (Hopefully)

[StoneyJackson]

@AksharP5 Good stuff!

Based on https://packaging.python.org/ I get the impression we should be using pyproject.toml. True?

[AksharP5]

@StoneyJackson

setup.py is fine to use instead of pyproject.toml I believe it is the older method (This is based on git-keeper), however pyproject.toml seems to be the newer standardized format so we can use that. Using poetry for this may be helpful, https://github.com/python-poetry/poetry

[StoneyJackson]

Python is beautiful. It's packaging ecosystem is not. It looks like things have improved changed since last I looked at it. Here are some readings that I found that might be useful to others, and might help provide a background if we ever reevaluate this decision later (and we probably will need to).

• https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/
• https://packaging.python.org/en/latest/guides/tool-recommendations/
• https://sinoroc.gitlab.io/kb/python/packaging_tools_comparisons.html#build-back-ends
• https://drivendata.co/blog/python-packaging-2023
• https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-build-tools.html
• https://chriswarrick.com/blog/2024/01/15/python-packaging-one-year-later/
• Use the [project] section in pyproject.toml according to PEP-621 python-poetry/poetry#3332

Based on the above (and maybe a few I didn't capture), here is my summary.

• There are an insane number of packaging tools in the Python ecosystem.
• pyproject.toml is the standard that everyone is trying to support. There are several PEPs that have standardized most if not all of it.
• setuptools was the first packaging tool. It has the largest marketshare. But it's lacking; that's why there are so many other tools.
• Poetry has the the second largest marketshare. It was using pyproject.toml before it was fully standardized. Now they are working to support the newest standards. It's been a couple of years. There is progress. But they are not done.
• Of the other tools, PDM and Hatch seam to be "doing it right". PDM is especially standards oriented.

My conclusion? Use pyproject.toml following modern standards. Use PDM for now. If Poetry comes up to standards, consider moving to it.

Note, even if we don't start publishing to PyPI, we still need a place to specify development and runtime dependencies, and pyproject.toml is a good place to do it.

[StoneyJackson]

PR #129 is becoming unwieldily. So I'm down scoping it. It will no longer attempt to distribute plcc through PyPI. But I think this is still a good goal. I'm moving the to-do list that was to here, so we don't lose it.

1. Add the version number in pyproject.toml to the bumpfile list for semantic release.
2. Add version="8.0.0" in src/plcc/init.py and use it in src/plcc/main.py to report the version. ("This is the way" https://stackoverflow.com/questions/30159202/how-pip-determine-a-python-package-version)
3. Add src/plcc/init.py to bumpfile list.
4. Create PyPI and PyPI test account.
5. Connect this to PyPI.
6. Add pdm commands to CI to push to PyPI (see https://pdm-project.org/latest/usage/advanced/#use-pdm-in-continuous-integration)
7. Update install docs
8. Update GitPod and devel docs

[StoneyJackson]

I got this working for https://github.com/ourPLCC/plcc-ng (and then disabled the workflow, because it's not ready for distribution).

So this might be possible here.