State push fails due to "empty branch"

Using state tool, I’ve been able to init a project, activate it, install dependencies, and reactivate it to update the build. But, whenever I try to do a “state push” I get the following:

x Cold not get branch for project
x Empty branch name provided

Note the typo…Cold should be Could. More importantly, note that between the words “branch” and “for” there are two spaces, suggesting it is trying to print an empty branch name.

I’m wondering if state push isn’t working because I am using a Free account. From what I see on the web site, you cannot create a branch on a Free account. Perhaps a branch is required.

If so, the message isn’t very helpful. If not, I’m stymied. I’ve tried cleaning the cache, cleaning the config, uninstall, a different project and build – it’s always the same result.

Hey @jgpuckering,

Thanks for the report! We appreciate you taking the time!

state push absolutely should work for Free accounts.

I imagine that this is the project you’re working with:

Any chance you can share the exact sequence of commands? That’ll help us debug.


Hi @jgpuckering, would mind sharing the following information:

  • Your state tool version (run state --version).
  • The first line of your activestate.yaml (should start with project: )

With that I should be able to get a better sense for how to further assist you.


Hi Zak,

I tried setting up a new 5.32.1 project, to test state push again. The sequence I ran was this:

  1. state init jgpuckering/ActiveState-5.32.1
  2. state auth
  3. state pull
  4. state activate

At this point I verified I had an install of 5.31.1 by running perl -v.

I added a perl script to the working folder I was doing all the above in, and then ran state push. I got the same result: empty branch.

I tried again by adding the project name, and then again by adding org/project, to the state push. No joy. “The project name argument is only allowed when pushing an anonymous commit”.

I’ve had zero success with state push in 5.28 or 5.32.

Thanks @jgpuckering ! Did you see @nathanr’s note about the version of the state tool and the first line of your activestate.yaml file (which should be in your project directory)?


Hi Nathan,

I’m now trying 5.32.1, but getting the same issue.

Here’s the project line from the yaml file (spaces inserted in the URL to get this through your spam filter):

project: https : // platform. activestate .com /jgpuckering /ActiveState-5.32.1?branch=main&commitID=d194cede-b7b7-4519-88e7-ce0800e5aa56

Here’s the output of state --version

ActiveState CLI by ActiveState Software Inc.
License BSD 3
Version 0.25.1-SHAd98b4c4
Revision d98b4c4d1cd84703ef80181814f9eac071ab9ad8
Branch release
Built Tue Mar 9 2021 19:29:10 +0000 GMT

Here’s the current working directory, within which I am activated:


Here’s the result of a state push:

║ Pushing Local Project ║
Pushing to project ActiveState-5.32.1 under jgpuckering.

Something Went Wrong
x Cold not get branch for project
x Empty branch name provided

1 Like

Thanks @jgpuckering, I’ve been able to reproduce your issue and have opened a bug internally to address it.

May I ask what your use-case is for wanting to run state push? For the most part you should not need to run it manually yet, the command is mainly there for some edge cases and for future use-cases that we’re still working on.

1 Like

Hey @jgpuckering - I’ve bumped your trust level on the forum. That /should/ fix the issue with URLs.

Interesting. This actually speaks to a problem I’ve been having getting my head wrapped around the workflow and what all the state tool commands are supposed to do. I’ve yet to find any documentation that really gives me a picture of the overall “theory” and how I’m supposed to apply it. That’s after working with it for two weeks.

What I was trying to accomplish – perhaps mistakenly – was to put a perl script in my activated project working directory and run state push thinking it would push it to the Platform, analyze it for dependencies, and add those dependencies to the build.

I also thought it might check it into the repository. I really had no idea whether the Platform was meant simply for building a perl distribution with an ability to add the cpan modules you want – or whether it served some greater purpose, such as combining a git repository for code management.

I’m guessing now it’s really just for building a distribution. What I’ve been doing is creating configurations and importing dependencies for my client. And also building configurations that include dependencies for my own personal environment (I have 130+ perl scripts that use 140+ non-core modules).

Any documentation you can point me to that explains the overall idea of ActiveState Platform – I mean in detail for a programmer like me who wants to use it day to day, not a marketing level overview – would be appreciated.

1 Like

I assume you’ve explored State Tool CLI :: ActiveState Platform Documentation?

I can appreciate that our docs don’t do a very good job of explaining what problems the State Tool is solving, I’ll forward that feedback internally. You can basically think of State Tool as a language agnostic package and virtual environment manager.

So state push is meant for you to “save” the changes you made to your project. But this is based on the future vision of being able to have a local state which is ahead of the one on the platform.

For your use-case you certainly wouldn’t want to use state push. While our platform does scan for vulnerabilities, it only does so based on the dependencies that you use in your project. If you are the author of a Perl module that you want to have covered by the ActiveState Platform it should really just be a matter of submitting it through regular contribution channels (ie. CPAN) and we should pick it up for you. @scottr or @shanew perhaps you can elaborate a bit more on this aspect and how @jgpuckering’s use case would apply to our platform.

The primary use-case is indeed for satisfying your runtime dependencies, like Perl and its modules. Though with the State Tool we do try to cover the extended use case of setting up your git repository and automating common tasks. We’re still in the early stages though, and so some growing pains are to be expected. That said feedback from users such as yourself is incredibly helpful. One major takeaway I have from this discussion is that we need to better explain the use-cases for the Platform and the State Tool.

I think the main docs page does a decent job summarizing the goals of the platform:

Though admittedly it probably leaves you wanting to learn more about those goals. I’ll try to get this actioned internally.

I’m sure @zakg can point you at some more resources in the interim.

Yes, I’ve read the documentation at the link you provided.

Since you’ve copied @scottr and @shanew, I should clarify my goal, which really is this:

Find a suitable path to upgrade from ActiveState perl 5.24 to ActiveState 5.28 (and beyond)

This goal entails several objectives:

  • find a means to replace the functionality of ppm, which is no longer available
  • upgrade my own personal perl Windows 10 environment
  • recommend an upgrade path for my client

My client has several small perl applications that run on Windows and Unix. For the most part, these are scripts which run as services that monitor the environment and take certain actions. For example, some scripts frequently access a database, some access LDAP servers, some just ping machines to see if they are online or offline. The scripts may send out email notifications.

These scripts need 40+ non-core modules.

My client packages their perl scripts and installs them at a client site. They may or may not have internet access from the account and machine they do the install from. Or admin access. So, offline installation is a requirement.

Typically, they have relied on perl either being installed on the customer machines, or have been permitted to install it. If the customer is using an older version than what is required for their scripts, they negotiate an upgrade with their customer to bring their version up to the necessary level.

To deal with offline installs, my client downloads the tarballs for all the modules they use and then deposit them onto the customers’ machine – after which they have used ppm to install them into the customers’ site lib.

So far, I have found two upgrade paths that seem workable:

  1. upgrade to Strawberry Perl and start using cpanm (in place of ppm).
  2. upgrade to ActiveState Platform and start using state tool (in place of ppm).

Path 1 results in a fairly painless upgrade and minimal impact on my clients’ current workflow. The just start using cpan and/or cpanm instead of ppm. I had quick success installing Strawberry Perl 5.28 and getting it to work with their software. I had minimal problems installing their 40+ modules.

Path 2 is one I’ve been exploring now for almost two weeks. I’ve run into various obstacles:

  • wasting time on state push, because I didn’t understand when or why to use it, the error messages didn’t help, the documentation didn’t help, and the email I sent to went unanswered.
  • problems with dependencies in 5.28
  • slow build times for 5.28 once I had a lot of dependencies; on the weekend builds were taking an hour
  • low productivity for 5.28 because every dependency change triggered a full rebuild
  • unable to run cpan or cpanm in order to download modules or tarballs
  • once I saw how builds were kept isolated by installing them in separate folders under %APPDATA%\Local\ActiveState, I ended up doing a lot of head scratching trying to figure out what this might mean for my clients’ scripts. It meant going from a system-wide perl install that scripts would use from whatever account they ran in, to a private perl install that must be activated within each .bat file. Will that even work from a script launched by cron? (I think they use pycron on Windows)

Once I got on the Community site and asking questions, some of the mysteries began to clear up. It was recommended that I try 5.32 – that it would build faster (incrementally). That has turned out to be the case. But, I’ve run into a couple of dependency and build issues (which I’ve posted). I’ve yet to get a successful 5.32.1 build with all the dependencies my client requires.

As for my goal of updating my own environment, I installed 5.28 at the system level and had a lot if issues installing all my modules. I got 95% there. But I use TCC (from jpsoft) as my command shell, and although it is a superset of cmd.exe I had issues using it with state tool – not the least of which is that state tool drops you into cmd.exe automatically, even when launched from TCC (with COMSPEC pointing to TCC.EXE). Even subshelling from the ActiveState instance of CMD to TCC doesn’t let you work in TCC without some issues. In the end, I resolved that the best thing to do was always use CMD (or bash, but I’m not that found of bash) when using ActiveState perl 5.28 and above.

I was aware, from the documentation, that TCC wasn’t a shell that was supported. Nonetheless, it is the shell I’ve been using for decades, I really like it, and I am loathe to abandon it.

The think is, none of these issues affect me when I use Strawberry Perl. It was about as smooth an upgrade as I could ask for. I simply started using cpanm and off I went.

So there you have it. Honestly, not a pretty story. I’ve been a user of ActiveState perl and python for a couple of decades. I even visited your office in Vancouver to see some of my former Cognos colleagues around 2000 I think. I’ve trying to keep an open mind, but the difference in the upgrade paths is just too hard to ignore.

Hey @jgpuckering!

Thank you so much for sharing this and for your persistence. You have no idea how much we appreciate it!

Can we set up a call with you to work through the issues?


Hi Zak,

Sure … we can set up a call. I’m available most anytime between about 10 am and 6 pm EDT. Let me know how you want to do the call. You probably have access to my email address, so you can reach me that way – since this is a public forum.

Great - I’ll be in touch privately.