Many in the open source community have expressed concern about the activities of Patrick McHardy in enforcing the GNU General Public License (GPL) against Linux distributors. Below are answers to common questions, based on public information related to his activities, and some of the legal principles that underlie open source compliance enforcement.
If you've ever built an online community, you know that the sheer number of options available can be daunting. Should you set up a forum, a Q&A site, or both? Would users prefer Slack, IRC, or perhaps a mailing list? Where does Telegram fit in? Maybe you should you just set up one of every available solution...
|
This is a guest post by Mark Waite, who maintains the git plugin, the git client plugin, and is a technical evangelist for CloudBees, Inc. |
The Jenkins project booth at Jenkins World 2017 will include the "Pull Requests Corner", recruiting new Jenkins contributors. We think there are many people who will attend the conference without realizing how easy it is to help the Jenkins project, and how much the help is appreciated.
Meet us in the "Pull Requests Corner" and we’ll help you find a way to help Jenkins. Here are some areas where we can use your help. Most of them do not require coding, and do not require a large time commitment.
The Jenkins changelog pages (LTS and weekly) gather user experiences with specific Jenkins versions. You can help other Jenkins users by clicking one of the weather icons in the LTS changelog (or the weekly changelog) for the release you’re using. Changelog feedback from weekly releases helps the release team select the long term support version. Changelog feedback from LTS releases helps other users prepare to upgrade.
It takes less than a minute, and helps the community (which will ultimately help you).
In five minutes or less, you can help other Jenkins users.
For example:
Answer a question on the #jenkins channel of internet relay chat (IRC)
Answer a question on the Jenkins users mailing list
Answer a question on stackoverflow jenkins, jenkins plugins, or jenkins pipeline
Answer a question on reddit
If you have ten minutes, you can learn something new and share what you learned.
Read a Jenkins community blog post and tweet it with the hashtag #jenkinsci
Read a devops.com blog post and share it on LinkedIn
Read a CloudBees blog post and test drive an idea from it
Find another Jenkins blog and share it (I recently discovered Matt Bajor’s ci/cd life blog)
Liam Newman has created the "Jenkins Minute" video series. They are brief video segments focusing on specific Jenkins functionality. Choose a video, watch it, and share what you learned on social media.
The Jenkins bug tracker contains thousands of bugs. Reviewing, duplicating, and clarifying bug reports takes time. When maintainers are reviewing, duplicating, and clarifying bug reports, they are not fixing bugs, and they are not adding new capabilities.
You can help maintainers by reviewing and duplicating a bug report that matters to you. A comment on a bug report is especially helpful when it confirms you’ve been able to duplicate the bug. It is even more helpful if your verification includes the steps you took and how they differ from the original report.
A bug report which has been duplicated, and includes clear instructions, is much more likely to receive maintainer attention. Help yourself and others by duplicating bugs that matter to you.
The Jenkins documentation includes user documentation (guided tour and handbook) and developer documentation (tutorial, how-to guides, and reference). You can help the documentation by describing something important to you clearly and completely.
Refer to the instructions for documentation contributors to see how easy it is to help.
If English is not your native language, you can help with Jenkins localization. Jenkins is used worldwide, and many users will benefit from translations. Considering the rapid and continuing evolution of Jenkins, it is no surprise that there is plenty to translate. Refer to the internationalization guide for instructions to help you contribute translations.
Local groups around the world meet often for Jenkins presentations, discussions, and demonstrations. Organizing a Jenkins Area Meetup will introduce you to other users, and will let you explore new ways to benefit from Jenkins. The team at jenkinsci-jam@googlegroups.com is ready to support your JAM with stickers, t-shirts, and more.
The Jenkins plugin ecosystem covers a wide range of areas. Jenkins plugin maintainers come from many different backgrounds, with many different interests. Often, a plugin maintainer may find that they want to do something different on the project, or they may leave the project. When a plugin maintainer is no longer able to maintain a plugin, they can place it for adoption.
Plugins placed for adoption range from very specific use cases (node stalker plugin) to very general use cases (Subversion plugin).
Maintaining an orphan plugin is a great way to contribute to the project. Follow the instructions to "Adopt a Plugin".
All those techniques (and more) are available on the Jenkins participate page.
Look for the "Jenkins Needs You" poster at Jenkins World, and come talk to us about the ways you can learn new things, address your concerns, and help Jenkins.
|
Join the Jenkins project at Jenkins World on August 30-31, register with the code |
Pythonistas! We're launching a new course today: Natural Language Processing (NLP) Fundamentals in Python by Katherine Jarmul.
In this course, you'll learn Natural Language Processing (NLP) basics, such as how to identify and separate words, how to extract topics in a text, and how to build your own fake news classifier. You'll also learn how to use basic libraries such as NLTK, alongside libraries which utilize deep learning to solve common NLP problems. This course will give you the foundation to process and parse text as you move forward in your Python learning.
Natural Language Processing Fundamentals in Python features interactive exercises that combine high-quality video, in-browser coding, and gamification for an engaging learning experience that will make you an expert in NLP!
What you'll learn:
Chapter 1: Regular expressions & word tokenization
This chapter will introduce some basic NLP concepts, such as word tokenization and regular expressions to help parse text. You'll also learn how to handle non-English text and more difficult tokenization you might find as you explore the wide world of NLP.
Chapter 2: Simple topic identification
This chapter will introduce you to topic identification, which you can apply to any text you encounter in the wild. Using basic NLP models, you will identify topics from texts based on term frequencies. You'll experiment and compare two simple methods - bag-of-words and Tf-idf using NLTK and a new library - Gensim.
Chapter 3: Named-entity recognition
This chapter will introduce a slightly more advanced topic - Named-entity recognition. You'll learn how to identify the who, what and where of your texts using pre-trained models on English and non-English text. You'll also learn how to use some new libraries - polyglot and spaCy - to add to your NLP toolbox.
Chapter 4: Building a "fake news" classifier
Here, you'll apply the basics of what you've learned along with some supervised machine learning to build a "fake news" detector. You'll begin by learning the basics of supervised machine learning, and then move forward by choosing a few important features and testing ideas to identify and classify "fake news" articles.
I was trying to test some code today and I realized I need a working PostgreSQL server. When I tried to start the server, it failed with this error.
Aug 23 15:36:10 athena systemd[1]: Starting PostgreSQL database server...
Aug 23 15:36:10 athena postgresql-check-db-dir[20713]: An old version of the database format was found.
Aug 23 15:36:10 athena postgresql-check-db-dir[20713]: Use 'postgresql-setup --upgrade' to upgrade to version '9.6'
Aug 23 15:36:10 athena postgresql-check-db-dir[20713]: See /usr/share/doc/postgresql/README.rpm-dist for more information.
Aug 23 15:36:10 athena systemd[1]: postgresql.service: Control process exited, code=exited status=1
Aug 23 15:36:10 athena systemd[1]: Failed to start PostgreSQL database server.
Aug 23 15:36:10 athena systemd[1]: postgresql.service: Unit entered failed state.
Aug 23 15:36:10 athena systemd[1]: postgresql.service: Failed with result 'exit-code'.
Ah, I upgraded to F26 recently and I suppose that came with a new version of PostgreSQL. I figured fixing this should be trivial. Well, not exactly. When I first ran the command, it asked me to install the postgresql-upgrade package. Once I did install it, the command threw a strange error.
[root@athena pgsql]# postgresql-setup --upgrade
* Upgrading database.
ERROR: The pidfile '/var/lib/pgsql/data-old/postmaster.pid' exists. Verify that there is no postmaster
running the /var/lib/pgsql/data-old directory.
ERROR: Upgrade failed.
* See /var/lib/pgsql/upgrade_postgresql.log for details.
The /var/lib/pgsql/data-old/postmaster.pid file doesn’t even exist. It took me some time to realize that it’s actually looking at /var/lib/pgsql/data/postmaster.pid, which does exist. I think at some point, I had a running PostgreSQL server and I didn’t shutdown the computer cleanly. This lead to a stale PID file. Once I renamed the PID file, the upgrade command worked.
This article is brought with ❤ to you by Semaphore.
This article will cover building a simple 'Hello World'-style web application written in Django and running it in the much talked about and discussed Docker. Docker takes all the great aspects of a traditional virtual machine, e.g. a self contained system isolated from your development machine, and removes many of the drawbacks such as system resource drain, setup time, and maintenance.
When building web applications, you have probably reached a point where you want to run your application in a fashion that is closer to your production environment. Docker allows you to set up your application runtime in such a way that it runs in exactly the same manner as it will in production, on the same operating system, with the same environment variables, and any other configuration and setup you require.
By the end of the article you'll be able to:
Dockerfile to build a container running a Django web application server.Docker's homepage describes Docker as follows:
"Docker is an open platform for building, shipping and running distributed applications. It gives programmers, development teams, and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications."
Put simply, Docker gives you the ability to run your applications within a controlled environment, known as a container, built according to the instructions you define. A container leverages your machines resources much like a traditional virtual machine (VM). However, containers differ greatly from traditional virtual machines in terms of system resources. Traditional virtual machines operate using Hypervisors, which manage the virtualization of the underlying hardware to the VM. This means they are large in terms of system requirements.
Containers operate on a shared Linux operating system base and add simple instructions on top to execute and run your application or process. The difference being that Docker doesn't require the often time-consuming process of installing an entire OS to a virtual machine such as VirtualBox or VMWare. Once Docker is installed, you create a container with a few commands and then execute your applications on it via the Dockerfile. Docker manages the majority of the operating system virtualization for you, so you can get on with writing applications and shipping them as you require in the container you have built. Furthermore, Dockerfiles can be shared for others to build containers and extend the instructions within them by basing their container image on top of an existing one. The containers are also highly portable and will run in the same manner regardless of the host OS they are executed on. Portability is a massive plus side of Docker.
Before you begin this tutorial, ensure the following is installed to your system:
Starting a Django application is easy, as the Django dependency provides you with a command line tool for starting a project and generating some of the files and directory structure for you. To start, create a new folder that will house the Django application and move into that directory.
$ mkdir project
$ cd project
Once in this folder, you need to add the standard Python project dependencies file which is usually named requirements.txt, and add the Django and Gunicorn dependency to it. Gunicorn is a production standard web server, which will be used later in the article. Once you have created and added the dependencies, the file should look like this:
$ cat requirements.txt
Django==1.9.4
gunicorn==19.6.0
With the Django dependency added, you can then install Django using the following command:
$ pip install -r requirements.txt
Once installed, you will find that you now have access to the django-admin command line tool, which you can use to generate the project files and directory structure needed for the simple "Hello, World!" application.
$ django-admin startproject helloworld
Let's take a look at the project structure the tool has just created for you:
.
├── helloworld
│ ├── helloworld
│ │ ├── __init__.py
│ │ ├── settings.py
│ │ ├── urls.py
│ │ └── wsgi.py
│ └── manage.py
└── requirements.txt
You can read more about the structure of Django on the official website. django-admin tool has created a skeleton application. You control the application for development purposes using the manage.py file, which allows you to start the development test web server for example:
$ cd helloworld
$ python manage.py runserver
The other key file of note is the urls.py, which specifies what URL's route to which view. Right now, you will only have the default admin URL which we won't be using in this tutorial. Lets add a URL that will route to a view returning the classic phrase "Hello, World!".
First, create a new file called views.py in the same directory as urls.py with the following content:
from django.http import HttpResponse
def index(request):
return HttpResponse("Hello, world!")
Now, add the following URL url(r'', 'helloworld.views.index') to the urls.py, which will route the base URL of / to our new view. The contents of the urls.py file should now look as follows:
from django.conf.urls import url
from django.contrib import admin
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'', 'helloworld.views.index'),
]
Now, when you execute the python manage.py runserver command and visit http://localhost:8000 in your browser, you should see the newly added "Hello, World!" view.
The final part of our project setup is making use of the Gunicorn web server. This web server is robust and built to handle production levels of traffic, whereas the included development server of Django is more for testing purposes on your local machine only. Once you have dockerized the application, you will want to start up the server using Gunicorn. This is much simpler if you write a small startup script for Docker to execute. With that in mind, let's add a start.sh bash script to the root of the project, that will start our application using Gunicorn.
#!/bin/bash
# Start Gunicorn processes
echo Starting Gunicorn.
exec gunicorn helloworld.wsgi:application \
--bind 0.0.0.0:8000 \
--workers 3
The first part of the script writes "Starting Gunicorn" to the command line to show us that it is starting execution. The next part of the script actually launches Gunicorn. You use exec here so that the execution of the command takes over the shell script, meaning that when the Gunicorn process ends so will the script, which is what we want here.
You then pass the gunicorn command with the first argument of helloworld.wsgi:application. This is a reference to the wsgi file Django generated for us and is a Web Server Gateway Interface file which is the Python standard for web applications and servers. Without delving too much into WSGI, the file simply defines the application variable, and Gunicorn knows how to interact with the object to start the web server.
You then pass two flags to the command, bind to attach the running server to port 8000, which you will use to communicate with the running web server via HTTP. Finally, you specify workers which are the number of threads that will handle the requests coming into your application. Gunicorn recommends this value to be set at (2 x $num_cores) + 1. You can read more on configuration of Gunicorn in their documentation.
Finally, make the script executable, and then test if it works by changing directory into the project folder helloworld and executing the script as shown here. If everything is working fine, you should see similar output to the one below, be able to visit http://localhost:8000 in your browser, and get the "Hello, World!" response.
$ chmod +x start.sh
$ cd helloworld
$ ../start.sh
Starting Gunicorn.
[2016-06-26 19:43:28 +0100] [82248] [INFO]
Starting gunicorn 19.6.0
[2016-06-26 19:43:28 +0100] [82248] [INFO]
Listening at: http://0.0.0.0:8000 (82248)
[2016-06-26 19:43:28 +0100] [82248] [INFO]
Using worker: sync
[2016-06-26 19:43:28 +0100] [82251] [INFO]
Booting worker with pid: 82251
[2016-06-26 19:43:28 +0100] [82252] [INFO]
Booting worker with pid: 82252
[2016-06-26 19:43:29 +0100] [82253] [INFO]
Booting worker with pid: 82253
You now have a simple web application that is ready to be deployed. So far, you have been using the built-in development web server that Django ships with the web framework it provides. It's time to set up the project to run the application in Docker using a more robust web server that is built to handle production levels of traffic.
One of the key goals of Docker is portability, and as such is able to be installed on a wide variety of operating systems.
For this tutorial, you will look at installing Docker Machine on MacOS. The simplest way to achieve this is via the Homebrew package manager. Instal Homebrew and run the following:
$ brew update && brew upgrade --all && brew cleanup && brew prune
$ brew install docker-machine
With Docker Machine installed, you can use it to create some virtual machines and run Docker clients. You can run docker-machine from your command line to see what options you have available. You'll notice that the general idea of docker-machine is to give you tools to create and manage Docker clients. This means you can easily spin up a virtual machine and use that to run whatever Docker containers you want or need on it.
You will now create a virtual machine based on VirtualBox that will be used to execute your Dockerfile, which you will create shortly. The machine you create here should try to mimic the machine you intend to run your application on in production. This way, you should not see any differences or quirks in your running application neither locally nor in a deployed environment.
Create your Docker Machine using the following command:
$ docker-machine create development --driver virtualbox
--virtualbox-disk-size "5000" --virtualbox-cpu-count 2
--virtualbox-memory "4096"
This will create your machine and output useful information on completion. The machine will be created with 5GB hard disk, 2 CPU's and 4GB of RAM.
To complete the setup, you need to add some environment variables to your terminal session to allow the Docker command to connect the machine you have just created. Handily, docker-machine provides a simple way to generate the environment variables and add them to your session:
$ docker-machine env development
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://123.456.78.910:1112"
export DOCKER_CERT_PATH="/Users/me/.docker/machine/machines/development"
export DOCKER_MACHINE_NAME="development"
# Run this command to configure your shell:
# eval "$(docker-machine env development)"
Complete the setup by executing the command at the end of the output:
$(docker-machine env development)
Execute the following command to ensure everything is working as expected.
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
You can now dockerize your Python application and get it running using the docker-machine.
The next stage is to add a Dockerfile to your project. This will allow Docker to build the image it will execute on the Docker Machine you just created. Writing a Dockerfile is rather straightforward and has many elements that can be reused and/or found on the web. Docker provides a lot of the functions that you will require to build your image. If you need to do something more custom on your project, Dockerfiles are flexible enough for you to do so.
The structure of a Dockerfile can be considered a series of instructions on how to build your container/image. For example, the vast majority of Dockerfiles will begin by referencing a base image provided by Docker. Typically, this will be a plain vanilla image of the latest Ubuntu release or other Linux OS of choice. From there, you can set up directory structures, environment variables, download dependencies, and many other standard system tasks before finally executing the process which will run your web application.
Start the Dockerfile by creating an empty file named Dockerfile in the root of your project. Then, add the first line to the Dockerfile that instructs which base image to build upon. You can create your own base image and use that for your containers, which can be beneficial in a department with many teams wanting to deploy their applications in the same way.
# Dockerfile
# FROM directive instructing base image to build upon
FROM python:2-onbuild
It's worth noting that we are using a base image that has been created specifically to handle Python 2.X applications and a set of instructions that will run automatically before the rest of your Dockerfile. This base image will copy your project to /usr/src/app, copy your requirements.txt and execute pip install against it. With these tasks taken care of for you, your Dockerfile can then prepare to actually run your application.
Next, you can copy the start.sh script written earlier to a path that will be available to you in the container to be executed later in the Dockerfile to start your server.
# COPY startup script into known file location in container
COPY start.sh /start.sh
Your server will run on port 8000. Therefore, your container must be set up to allow access to this port so that you can communicate to your running server over HTTP. To do this, use the EXPOSE directive to make the port available:
# EXPOSE port 8000 to allow communication to/from server
EXPOSE 8000
The final part of your Dockerfile is to execute the start script added earlier, which will leave your web server running on port 8000 waiting to take requests over HTTP. You can execute this script using the CMD directive.
# CMD specifcies the command to execute to start the server running.
CMD ["/start.sh"]
# done!
With all this in place, your final Dockerfile should look something like this:
# Dockerfile
# FROM directive instructing base image to build upon
FROM python:2-onbuild
# COPY startup script into known file location in container
COPY start.sh /start.sh
# EXPOSE port 8000 to allow communication to/from server
EXPOSE 8000
# CMD specifcies the command to execute to start the server running.
CMD ["/start.sh"]
# done!
You are now ready to build the container image, and then run it to see it all working together.
Building the container is very straight forward once you have Docker and Docker Machine on your system. The following command will look for your Dockerfile and download all the necessary layers required to get your container image running. Afterwards, it will run the instructions in the Dockerfile and leave you with a container that is ready to start.
To build your container, you will use the docker build command and provide a tag or a name for the container, so you can reference it later when you want to run it. The final part of the command tells Docker which directory to build from.
$ cd <project root directory>
$ docker build -t davidsale/dockerizing-python-django-app .
Sending build context to Docker daemon 237.6 kB
Step 1 : FROM python:2-onbuild
# Executing 3 build triggers...
Step 1 : COPY requirements.txt /usr/src/app/
---> Using cache
Step 1 : RUN pip install --no-cache-dir -r requirements.txt
---> Using cache
Step 1 : COPY . /usr/src/app
---> 68be8680cbc4
Removing intermediate container 75ed646abcb6
Step 2 : COPY start.sh /start.sh
---> 9ef8e82c8897
Removing intermediate container fa73f966fcad
Step 3 : EXPOSE 8000
---> Running in 14c752364595
---> 967396108654
Removing intermediate container 14c752364595
Step 4 : WORKDIR helloworld
---> Running in 09aabb677b40
---> 5d714ceea5af
Removing intermediate container 09aabb677b40
Step 5 : CMD /start.sh
---> Running in 7f73e5127cbe
---> 420a16e0260f
Removing intermediate container 7f73e5127cbe
Successfully built 420a16e0260f
In the output, you can see Docker processing each one of your commands before outputting that the build of the container is complete. It will give you a unique ID for the container, which can also be used in commands alongside the tag.
The final step is to run the container you have just built using Docker:
$ docker run -it -p 8000:8000 davidsale/djangoapp1
Starting Gunicorn.
[2016-06-26 19:24:11 +0000] [1] [INFO]
Starting gunicorn 19.6.0
[2016-06-26 19:24:11 +0000] [1] [INFO]
Listening at: http://0.0.0.0:9077 (1)
[2016-06-26 19:24:11 +0000] [1] [INFO]
Using worker: sync
[2016-06-26 19:24:11 +0000] [11] [INFO]
Booting worker with pid: 11
[2016-06-26 19:24:11 +0000] [12] [INFO]
Booting worker with pid: 12
[2016-06-26 19:24:11 +0000] [17] [INFO]
Booting worker with pid: 17
The command tells Docker to run the container and forward the exposed port 8000 to port 8000 on your local machine. After you run this command, you should be able to visit http://localhost:8000 in your browser to see the "Hello, World!" response. If you were running on a Linux machine, that would be the case. However, if running on MacOS, then you will need to forward the ports from VirtualBox, which is the driver we use in this tutorial so that they are accessible on your host machine.
$ VBoxManage controlvm "development" natpf1
"tcp-port8000,tcp,,8000,,8000";
This command modifies the configuration of the virtual machine created using docker-machine earlier to forward port 8000 to your host machine. You can run this command multiple times changing the values for any other ports you require.
Once you have done this, visit http://localhost:8000 in your browser. You should be able to visit your dockerized Python Django application running on a Gunicorn web server, ready to take thousands of requests a second and ready to be deployed on virtually any OS on planet using Docker.
After manually verifying that the application is behaving as expected in Docker, the next step is the deployment. You can use Semaphore's Docker platform for automating this process.
As a first step you need to create a free Semaphore account. Then, connect your Docker project repository to your new account. Semaphore will recognize that you're using Docker, and will automatically recommend the Docker platform for it.
The last step is to specify commands to build and run your Docker images:
docker build <your-project> .
docker run <your-project>
Semaphore will execute these commands on every git push.
Semaphore also makes it easy to push your images to various Docker container registries. To learn more about getting the most out of Docker on Semaphore, check out our Docker documentation pages.
In this tutorial, you have learned how to build a simple Python Django web application, wrap it in a production grade web server, and created a Docker container to execute your web server process.
If you enjoyed working through this article, feel free to share it and if you have any questions or comments leave them in the section below. We will do our best to answer them, or point you in the right direction.
This article is brought with ❤ to you by Semaphore.
Let's take a trip back in time to the 1990s, when proprietary software reigned, but open source was starting to come into its own. What caused this switch, and more importantly, what can we learn from it today as we shift into cloud-native environments?
I've been working on a data scraping project for a customer and started using Apache Tika after some experimentation showed me that it does a nice job of pulling text out of PDF files. This week, I was confronted with a new data source in DBF format, and it turns out Tika handles that as well.
The traditional way of package deployment on Python is using a setup.py script located in the root of your project and then running python setup.py sdist upload to release a new version.
It works by using distutils, setuptools or distribute and there is also twine which is a command line application to manage uploads.
distutils is the standard way of Python package distribution included in standard library since Python 2.x then setuptools was created to overcome distutils limitations and also introduces a command line application called easy_install (which is now pip) and a very handy feature called pkg_resources and one of the characteristics of setuptools is that it uses Monkey Patching over the standard distutils.
Some forks of setuptools has been created to fix some issues and ad common developers preferences and well known forks like distribute and distutils2 and distlib has been merged back to the original setuptools
Lots of other packaging tools has been created to try to fix the distribution problems.
using one of the above you should create a file called setup.py in the root of your project, e.g:
from <my_favorite_dist_tool> import setup
# Example taken from Django's repository
setup(
name='Django',
version=version,
url='http://ift.tt/q4NHeK',
author='Django Software Foundation',
author_email='foundation@djangoproject.com',
description=('A high-level Python Web framework that encourages '
'rapid development and clean, pragmatic design.'),
license='BSD',
packages=find_packages(exclude=EXCLUDE_FROM_PACKAGES),
include_package_data=True,
scripts=['django/bin/django-admin.py'],
entry_points={'console_scripts': [
'django-admin = django.core.management:execute_from_command_line',
]},
install_requires=['pytz'],
extras_require={
"bcrypt": ["bcrypt"],
"argon2": ["argon2-cffi >= 16.1.0"],
},
zip_safe=False,
classifiers=[
'Development Status :: 2 - Pre-Alpha',
'Environment :: Web Environment',
'Framework :: Django',
'Intended Audience :: Developers',
'License :: OSI Approved :: BSD License',
'Operating System :: OS Independent',
'Programming Language :: Python',
'Programming Language :: Python :: 3',
'Programming Language :: Python :: 3.4',
'Programming Language :: Python :: 3.5',
'Programming Language :: Python :: 3.6',
'Topic :: Internet :: WWW/HTTP',
'Topic :: Internet :: WWW/HTTP :: Dynamic Content',
'Topic :: Internet :: WWW/HTTP :: WSGI',
'Topic :: Software Development :: Libraries :: Application Frameworks',
'Topic :: Software Development :: Libraries :: Python Modules',
],
)
As you can see it is very confusing to decide which of them to addopt and how the setup.py should be writen because there are different examples over the github most famous Python repositories.
NOTE: Forget about all that history you read above and consider Flit.
Flit is a simple way to Package and deploy Python projects on PyPI, Flit makes it easier by using a simple flit.ini file and assumes common defaults to save your time and typing.
I knew Flit when I was taking a look at Mariatta Wijaya game called Tic Tac Taco Pizza and noted that she used flit to deploy the game, so we also asked her the reason on the podcast we recorded so I decided to try porting my projects to Flit.
Instead of a setup.py you put a flit.ini in the root of your project and it looks like:
[metadata]
module = markdocs
author = Bruno Rocha
author-email = rochacbruno@gmail.com
maintainer = rochacbruno
maintainer-email = rochacbruno@gmail.com
home-page = http://ift.tt/2w1LXQ7
requires = mistune
click
description-file = README.md
classifiers = Programming Language :: Python :: 3.6
Intended Audience :: Developers
License :: OSI Approved :: MIT License
Topic :: Documentation
Topic :: Software Development :: Documentation
Topic :: Software Development :: Quality Assurance
requires-python = >=3.6
[scripts]
markdocs = markdocs:main
Now you only need to have flit installed in your local machine pip3 install flit as it works only in Python3+ and also is recommended to have pandoc and pypandoc also installed because it can convert your README.md into the .rst format still used by PyPI.
The advantages are:
setup.py__version__ included in your program/__init__.pysetup.pyTo install your package during development use
flit install --symlink --python path/to/virtualenv/bin/python
the
--pythonis optional, by default will take the currentwhich python
It is easy and will register the new project for you if doesn't exist on PyPI
flit puslish
Flit packages a single importable module or package at a time, using the import name as the name on PyPI. All subpackages and data files within a package are included automatically.
~/.pypirc to authenticate and to find the server deployment addressesFLIT_USERNAME and FLIT_PASSWORD and FLIT_INDEX_URL as environment variables which makes flit good for CI deployment (e.g: TravisCI)NOTE: Flit is open-source, so some of this things are already under consideration.
requirements.txt file and would be nice to have it as tools like pyup.io can track those files but not flit.ini yet.lock frozen file with the version used on specific release and it is interesting just like pipenv doesFlit is the easier way to deploy packaged to PyPI following 3 steps (1. install flit, 2. describe flit.ini 3. run flit publish) your library is released to PyPI.
But Python still needs better standards because you still need separated tools to make common tasks and using a single tool to pack, install, deploy, create would be better (just like what cargo/crates does for Rust) for example, in Python you have:
So many tools brings a lot of confusion and makes it hard to choose, why not having a single tool, based on different plugins sharing the same API?
python -m manage [install packagename] # <-- calls pip or pipenv
[publish --options --bump=version] # <-- calls `flit` and `bumpversion`
[new packagename templatename] # <-- calls cookiecutter
[safecheck] # <-- calls safety
[checkupdates] # <-- checks in the same way as Pyup
[test path] # <-- calls pytest, nose or unittest
[lint path] # <-- calls flake, pylint
[venv options] # <-- calls the existing venv module
All above configurable via config file or env vars.
and each of that endpoints would be provided by many plugins sharing the same API, so you could choose between flit or twine as your publish manager etc..
So maybe I can implement that features in manage
Please share in comments if you know some other Python management tool
Ever wondered what two underscores around variables means? You may have seen __name__, __str__, __doc__, or other "double underscore" variables in Python. What are these "dunder" variables and what are they for? This week we'll do a Q&A about dunder variables.