Below are some commonly asked questions by ActiveState users. If you have questions please check the online community forums. They are regularly maintained by ActiveState staff and are contributed to by other members of the ActiveState community. For questions related to your account, reach out to contact us.
Your ActiveState project will not use any first-party or proprietary code produced by you or anyone else with whom you have shared the project. All user-generated code does not become part of the shared properties of your project, nor does it belong to ActiveState.
Details on how to share your project can be found here.
The benefits of sharing your ActiveState project include
No, the invite email is specific to your email address and your organization. If you would like to provide access to other people in your organization you can either sign up for the Platform yourself and invite them, or contact us with the email addresses of the users to invite, and we will send them individual invites (this is only available for paid tiers).
The time needed to build your project can vary depending on
A small build with fewer packages and dependencies may only take seconds or minutes to build successfully. Larger, more complex projects can take several minutes or even hours to build successfully.
In cases where a build process appears stuck, try resetting the build by making a minor change to your configuration. For example, changing the version of an existing package, adding a new package, changing the version of the language, etc.
A Common Vulnerability and Exposures (CVE) identification is the unique identifier that is given to a specific vulnerability by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD). Each CVE has been reviewed by a governing body (the CVE Numbering Authority) and found to present a credible threat to the security of a system. Check here to find out more about CVEs and how the ActiveState Platform and the State Tool deal with them.
Organizations are the way you group ActiveState Platform projects for a company, department, or team. Members of the organization will have access to each project in the organization, with the ability to invite others to join, remove users, and create or modify runtimes (depending on the role of the user).
You can create paid organizations that support both private and public projects, or free organizations that only support public projects.
Komodo IDE and Komodo Edit have been opensourced. Check out our blog article to find out more.
All current license agreements can be found here, and agreements for older versions or legacy products can be found here.
Information on deprecated products and languages can be found on the ActiveState documentation homepage. These docs are for archival use only and are not updated.
Details on how to delete your account can be found here. Note that deleting your account will not automatically uninstall the State Tool from your machine.
Instructions on how to download the files from your project can be found here.
The minimum OS requirements to run your project are
Each runtime is created and executed in a virtual environment that will avoid conflicts between other projects, production environments, and the developer environments of other developers (if the runtime has been shared). Using the ActiveState Platform, each runtime can be easily updated to include the most current and secure versions of all dependencies/packages/binaries/etc.
Instead of offering a pre-packaged downloadable installer, the State Tool creates a virtual environment on your system allowing you to run concurrent and disparate development environments that contain all (and only) the packages you need for your projects, without conflicts or interfering with the preexisting language versions on your system.
Installers are available for Enterprise tier users. Click here to find out more
Each ActiveState project (and the associated runtime) is installed in its own virtual directory to prevent dependency conflicts. When you activate a runtime you’re setting up a virtual environment to work from. This keeps your dependencies separate from those outside of the virtual environment’s parameters. This is important because
After exiting your runtime, files are cached on your local system until deletion. This helps keep reloading time fast. Regularly using the state pull command will keep your project, and its virtual environment, up to date on your local installation.
You can end your activated state by typing exit into the command prompt or terminal window. Closing the command prompt or terminal window will also deactivate your project.
You can find instructions for location-specific installations in the checkout documentation here.
ActiveState currently has integrations with several popular IDEs including Visual Studio Code, Pycharm, and Eclipse. More information about integrations can be found here.
For organizations with Service Level Agreements (SLA), use the contact information included in your SLA to request specific packages. When requesting a new package, include the name of your organization and project, as well as the package and, when possible, the package version.
Users without an SLA can post a request on the community forums. Feel free to include as much information as you feel comfortable disclosing, including your organization or project name, and package version. These requests will be processed according to their availability and user demand.
Organizations with SLAs are encouraged to use the contact information provided in their agreement to receive assistance from ActiveState. Users without an active SLA can try to review and edit any CVEs that may be causing the build to fail, or ask for help on the community forums.
After making changes to your project using the Platform, open the project using the State Tool by starting a shell or activating the project. Then run state pull. This will update your project with the changes made on the Platform.
If you experience trouble installing your runtime, make sure that the OS version on your local machine meets the minimum standards.
The recommended version of each language is based on Platform build success rates and the availability of new open source package versions. ActiveState continuously updates these recommended versions as more recent versions of the language ecosystem become stable and vetted by the open source community.
To work with more than one project on your system, check out each project to different directories and then deploy them separately from each directory by running state shell <orgname>/<projectname>. Each shell environment is temporary, and once the working session has ended (either by typing exit into the terminal or closing the application) it will need to be re-deployed each time you work on your project.
We recommend not editing your PATH variable and instead, using the state checkout <orgname/projectname> and state use <orgname/projectname> (to set your runtime as your default installation) or state shell <orgname/projectname> (to open a secure shell in which to use your runtime) commands to interact with your Perl installation.
If you still choose to edit your PATH variable, adding your project at the \exec folder (not the \site or \bin folder) will direct your machine to the correct directory needed for your project. This will only let you add a single Perl project as your system default, as your machine will always select the first Perl addition from the top of the list and continue using that version for all projects.
Note that for Perl 5.28 and earlier, you will need to add your project at the \bin folder.
While traditionally .exe files are executables responsible for installing and running applications on your machine, the perl.exe file located in your project control folder may be different.
Some of the perl.exe files in your projects act as wrappers set up around the original perl.exe file that set up PATH and search variables to point to the correct version of the executable file that matches what is needed for your project. This is why pointing the PATH variable to the /exec folder of your project is important to ensure your projects work as intended.
A validation error with the following text may be shown when attempting to produce an installer or Docker image for your project.
" Validation error: Selected language uses an old build system that cannot produce an installer or Docker image. Please select a newer language version or remove the selected platform deployment option.”
A validation error occurs between the build request from the user and the current build architecture of the Platform. To increase the likelihood of a successful build, select a more recent language version for your project or change the OS settings of the project (i.e. only selecting “Linux” for a Docker image). Attempt the build again with these changes in effect. If the problem persists, please contact us.
Open your command prompt or terminal and type state update
To check out a project on your local machine enter state checkout <orgname>/<projectname> <path to folder>
For example state checkout JohnSmith/Project1 C:\project
To check out a project’s bits to your local machine enter state checkout <orgname>/<projectname> --runtime-path <path to folder>
For example state checkout JohnSmith/Project1 --runtime-path C:\project
To display all existing projects, their location on your system, and the location of their executable files enter state projects.
Working from your project directory (the folder containing your activestate.yaml file) enter the command state pull.
You can use the State Tool to check your current project for any potential vulnerabilities by activating the project and running state cve to view the vulnerabilities associated with that project.
For a more detailed explanation of the vulnerabilities associated with your project, enter state cve report. This will include an ID for each listed vulnerability so you can look them up to see how they may impact the security or performance of your project. To address the vulnerabilities found in your project see here.
state projects in your terminal to view a list of the projects that are installed locally on your machine.exit into the command line. This will deactivate your project.state shell <orgname/projectname> to activate the project you want to switch to. If you want to set a new default project for your system enter state use <projectname>. This will be the default project until you set a new default using state use or unset a default by entering state use reset.You can end your working session by typing exit into the command prompt or terminal window. Closing the command prompt or terminal window will also deactivate your project.
Comparing different versions of the same project is a great way to make sure changes have been logged and to track the progress of your projects. To compare two separate projects (“project1” and “project2” in “organization1”)
state shell <organization1/project1> into your command prompt.state run <script1>.state shell <organization1/project2> into your command prompt.state run <script2> in the newly created windows and wait for the script to stop.exit into either or both terminal windows to end your working session(s).There are two separate commands to uninstall your activated project, each with unique characteristics.
state clean cache will remove all copies of cached versions of everything and reset the State Tool cache. This command will not uninstall the State Tool. This needs to be done from the main project directory, although it may work from other directories with newer language versions.state clean uninstall gets rid of cached files, uninstalls the State Tool, installed language runtimes, and all configured information. It’s important to note that after confirming your choice to run this command, you will need to restore everything from the Platform. To find out more see here.If you are updating from a much older version it may have problems with runaway services that may be preventing the update. The State Tool Troubleshooting section has instructions on identifying and shutting down runaway services for Windows, macOS, and Linux. After running the script to stop ongoing processes, enter state update to resume your update.
Generally, the “could not figure out what path to use” means that the State Tool can’t find a suitable folder for your runtime. Unsuitable folders include program folders, system folders, or folders where restrictive permissions have been set. Your personal folders are more likely to be writable and are a better choice for your project. Follow the steps here to check out a project to a specific location on your system.
If you receive this error, you can try resolving the error in the Platform. The Platform provides more feedback and can see if (and when) the rebuild succeeds. That will show when the State Tool can find a working build of the module to download from your project.
The Platform will also allow you to specify the package version and see immediately if there are any vulnerabilities associated with it. Check here for more information about adding packages using the Platform and here for information about vulnerabilities.
The State Tool cannot download Tcl projects, you must go to the Platform and download the .msi or .tar file directly from the project page to install your Tcl project on your local machine.
To install the State Tool on a server you will need to checkout the project to a specific location on the server. To do so enter state checkout <orgname>/<projectname> <location>. This will place a project folder containing your project’s activestate.yaml file into the specific location. To checkout all of the bits associated with your project enter state check out <orgname>/<projectname> --runtime-path <location>. More information on state checkout can be found here.
This error may indicate that your current working directory is incompatible with the State Tool (for example a System32 or similar directory), or you are trying to deploy your project as an Admin on your local system. After checking out a project your runtime will be installed into a personal (or user) AppData folder. Only users can access the runtime. Try exiting as an Admin, logging in as a user, and re-deploying the runtime.
This error may result from trying to install a package while being behind a proxy server. Click here for more details and potential solutions
Can I test a Perl installation for free?
What happens if I have to run tests on a system which is very secure?
Can I test with a runtime of an older language version?
What does a subscription provide?
What is the difference between Perl 5.32 and 5.36?
What do I do if my PERL5LIB variable is not set up right?
How can I have multiple Perl builds on my system?
Where do I add my Perl project in my PATH variable? (Windows only)
What does the perl.exe file in my project do?
How do I get rid of a “can’t load” error on my Perl project?
Why is there no compiler included in my project?
How do I compile code for my project?
You can do testing with a Free tier account, but the free accounts may not include some features that might be needed to test in your environment. Free accounts only have access to the most recent products, and must have unrestricted internet access. If your workplace is very secure, you may have to learn the process from a PC with unfettered access to an internet connection.
For basic testing, and for learning how to use The Platform, start with a desktop PC running Windows 11, a recent feature pack of Windows 10, or a current desktop Linux. Use a PC that has direct access to the internet, or at most is only behind a single proxy server with known credentials.
There are optional offline installers available to Enterprise Tier organizations, and to Team Tier organizations with an add-on in the contract. These must be paid for upfront, whether the runtime will work for you or not. This requirement also multiplies the impact of not knowing exactly what you need in your project, and will generally result in an update that requires months of refinements to complete, rather than weeks or days. If you can possibly test in a less restricted system, it’s highly advisable.
The long upgrade process to move a potentially insecure installation may not be the best use of resources, as it will only offer you a few months of service life (or none at all). If you are constrained by the operating systems you have in service, it is preferable if you upgrade to newer systems and then use newer software (including a newer version of Perl).
Free tier users do not have access to older versions. You might be required to start with Team, or even Enterprise Tier, to get the older version you want. Currently, no tier has access to every version of Perl shipped since the 1990s. Unfortunately, releases do eventually get old enough that they are incompatible with all currently supported versions of an operating system, or are far enough into end-of-life that we can no longer responsibly distribute them. When possible, older versions will be available at the final rollup release. If what you are looking for is not available, you may need to adjust your expectations so they are in line with what is safe, reasonable, available, and affordable.
The Platform is an online build and testing (CI) service. We no longer have a business model where the product is free/gated access to a library of never-changing downloads. Instead the Platform offers a constantly updates package library where you can choose all andonly the Perl modules you need for your project.
There isn’t a “standard” set of content (ActiveState dropped the concept of the Community Editions in 2021). Now all content is managed by the users. You can tailor your runtime to exactly what you need; no more and no less. What is available for the new releases are templates, but you will need to have a solid idea of the content that will need to be added or removed from the template to make up the project you will need.
Perl will always use OpenSSL. The core pulls it in so that it can support secure socket connections for networking. Perl never uses a third-party OpenSSL library. If you have a setup that allows Perl to find and load an incompatible third-party version, it will crash. Usually, the culprit is the order of the PATH variable
So the default behavior is for Perl to use its own OpenSSL install, but if there is an odd ordering for PATH that puts some other application (that happens to have OpenSSL) first, then that could result in an incompatible version being pulled. If you have a copy of the Microsoft Dependency Walker tool, you can usually see where a bad library is located.
5.32 and 5.36 are very similar. There’s a big discontinuity at 5.26 (the change to @INC to remove loading from the current working directory). Then at 5.32 there’s a builder change that generates all Perls as single-threaded by default. Those changes both happen between where you are now, and 5.32. OpenSSL 3 is working with the 5.34 and 5.36 on a more limited set of modules. These Crypt-OpenSSL modules are probably going to tie you to OpenSSL 1.1.1 for a while.
The Perl variables should be at, or near, the top of the variable listing, including the PERL5LIB variable. If the variable exists, look at where it’s pointed, this could impact your system setup.
Oracle Servers still set PERL5LIB, and they have their own version of Perl. One way to determine if the variable is set correctly is to see if your PERL5LIB folder has binaries in it. They may be missing or pointed to the wrong folder. And if the binaries were compiled for 5.24, they would need to be used with a 5.24.
To work with more than one project on your system, check out each project to different directories and then deploy them separately from each directory by running state shell <orgname>/<projectname>. Each shell environment is temporary, and once the working session has ended (either by typing exit into the terminal or closing the application) it will need to be re-deployed each time you work on your project.
We recommend not editing your PATH variable and instead, using the state checkout <orgname/projectname> and state use <orgname/projectname> (to set your runtime as your default installation) or state shell <orgname/projectname> (to open a secure shell in which to use your runtime) commands to interact with your Perl installation.
If you still choose to edit your PATH variable, adding your project at the \exec folder (not the \site or \bin folder) will direct your machine to the correct directory needed for your project. This will only let you add a single Perl project as your system default, as your machine will always select the first Perl addition from the top of the list and continue using that version for all projects.
Note that for Perl 5.28 and earlier, you will need to add your project at the \bin folder.
While traditionally .exe files are executables responsible for installing and running applications on your machine, the perl.exe file located in your project control folder may be different.
Some of the perl.exe files in your projects act as wrappers set up around the original perl.exe file that set up PATH and search variables to point to the correct version of the executable file that matches what is needed for your project. This is why pointing the PATH variable to the /exec folder of your project is important to ensure your projects work as intended.
If your project is unable to load, or certain .dll files fail to load, you can try adding it directly to your PATH variable. For Perl 5.28 add the (Perl)\bin folder to PATH, and for Perl 5.32 and higher, you need to also add (Perl)\exec. If that does not solve the issue try adding the folder in front of the \bin and site\bin folders.
Including a compiler would be redundant and unnecessary, as your ActiveState project has already been “compiled” by the Platform during the build process prior to you checking it out on your local system. The source code needed for your project has already been translated into machine code (or an appropriate intermediate code) by the Platform before it arrives on your local system. The interpreter in your project arrives compiled.
After your project has been built compiling your project is not necessary. Your ActiveState project has already been “compiled” by the Platform during the build process, prior to you checking it out on your local system. The interpreters in your project are already compiled.
If you need to compile your project after you have added custom content, for example, building modules from the source code on CPAN on local systems, you can use existing pre-packaged compilers (GCC, MinGW, etc.) to re-compile the project. ActiveState support for specific compilers is on a best-effort basis and, as a result, your project is not guaranteed to work with all existing compilers. If the compilers are not working within your project, you can use them in parallel to our tool, or use Strawberry Perl, Cygwin, Windows Subsystem for Linux (WSL), or Chocolatey to compile.
Details on these CVEs can be found in our documentation.